EEPROM

[Stefox]

Bonjour,

J'ai réalisé un code pour une eeprom (24FC1026) avec un pic18F46K22. J'ai su stocker des données plus d'un mois, tout s'est bien passé et j'ai ensuite voulu le faire évoluer et j'ai modifié plusieurs trucs dans l'eeprom mais aussi ailleurs.. Sauf que depuis, certaines données sont incohérentes dans la mémoire. Et j'ai pas fait de backup (grosse erreur oui..)

J'ai du 5V stable, condo de découplage associé proche de VCC, GND des composants.

J'ai fait un scan I2C qui est OK et NOK si j'enlève l'eeprom.

Bref niveau physique, j'ai pas trop de doute.

Cependant, dans mon code je me suis très certainement raté dans une modification et je ne parvient pas à percer ce mystère rendant mon circuit plutôt très inutile..

Je stock plusieurs données dans des espaces réservé. Prenons un exemple, je stock "SetPoint_Temp" (Variable globale). Au démarrage, sans l'avoir modifié il est a 26 (J'ignore ou il trouve 26 mais voila, c'est 26 même si j'initialise la variable globale a 20 par exemple dans le code..) Je stock donc 30 moi meme via mon menu utilisateur (Fichier Settings.c) et quand je retourne chercher la valeur, je retrouve bien 30. Mais si je coupe le jus, je revient a 26 d'après mon retour LCD..

Cependant, la variable SetPoint_Brightness (Variable globale) elle, si je stock 6, quand je coupe le jus et le remet, je recupére bien 6, elle, aucun souci.. Pareil pour le stockage de code a 4 chiffres que je fais, j'ai testé, il semble fonctionner

Je transmet le code EEPROM et la fonction de mon menu pour les 2 fonctions (tout au fond du fichier). Je précise que je suis amateur, ce n'est pas mon métier donc mon code va peut-être piquer certains Si vous voulez voir autre chose pour pouvoir m'aider, dites-moi ! ;)

Je serai par contre ravis d'avoir des retour constructif sur mon code eeprom pour le rendre meilleur, plus fiable dans le temps, ...

Merci d'avance,

Stefox.

[gwion]

Bonsoir,
Et si tu relis l'EEPROM juste après avoir écrit la valeur, tu trouves quoi ?

[Stefox]

Bonsoir Gwion ! :)

Via le menu utilisateur (Settings.c) je peux regler Setpoint_Temperature. Pour l'éditer je vais la chercher dans l'eeprom (La première fois que je met le jus), et j'obtiens 26 (J'ignore d'ou viens ce magic number). Je la modifie et j'écris 30 et valide. Le programme l'écrit et me renvoie dans le menu principal. Si je retourne la modifier, il va la lire et j'obtiens bien 30.

Seulement si après tout ça, je coupe le jus et je le remet, je recupère 26.

On dirait comme si elle était écrasé au démarrage, mais rien ne me saute aux yeux..

[satinas]

Bonjour,
Cela fait 2 fois, pas de sauvegarde. Je sais bien que lorsqu'on est content d'avoir un programme qui schtroumpfe bien, on se dit je vais en schtroumpfer un peu sans schtroumpfer avant et ça schtroumpfera aussi bien, mais ce n'est pas comme cela que ça schtroumpfe
Cela ne coûte rien de faire un clic droit zip du dossier projet tous les soirs en incrémentant le nom du fichier, il y a 40 ans pour sauvegarder il fallait installer une bande magnétique sur un dérouleur, et on payait une personne pour le faire. Aujourd'hui c'est tout simple.
Et tant qu"à faire il vaut mieux sauvegarder sur clé USB car un disque dur peut lâcher. Cela dépend bien sûr du niveau d'importance du programme.

J'écris tout cela car je ne sais pas quoi dire d'autre à part quelques remarques.
- Tu as tendance à mettre un même define dans plusieurs fichiers header, il ne doit figurer qu'à un seul endroit.
- Pourquoi mettre des variables globales en argument de fonction ?
- Je ne le sens pas ce passage, je ne vois pas trop ce qu'il fait exactement, surtout le ||, cela dépend du type d'eeprom.
while (I2C2_Start() || I2C2_WriteAddr(bankAddr)) {
I2C2_Stop(); // EEPROM n?est pas prête, on stoppe et réessaie
}
- Si le temps n'est pas un problème tu peux faire un read eeprom systématique en fin de fonction write eeprom et sortir un message d'erreur si problème d'écriture.
- Le 26 que tu obtiens au démarrage, c'est avant ou après lecture de l'eeprom. Je suppose après, si au démarrage tu lis et affiche toutes les data de l'eeprom, elles sont toutes fausses ?
- De toute façon il faudrait voir le main.c, c'est ce que me dit ChatGPT et je rajoute l'i2c.c aussi, bref déballe tout

[Stefox]

Bonjour,

En fait je fais des backup de la veille, mais le surlendemain, je l'écrase par la nouvelle, je fais pas de backup sur backup, ce que j'aurai peut etre dû faire. Je n'ai pas remarqué tout de suite que l'eeprom fonctionnait pour la sauvegarde des codes et du brightness mais plus pour le SP Temp car cette fonction a été faite bien avant et je n'avais pas trop de raison d'y toucher donc je ne l'ai pas re-test, je n'ai donc plus la backup originel fonctionnel ^^ Et j'ignore depuis quand ça foire mais voila ^^

Voici le main, l'i2C, l'eeprom et le settings. :)

eeprom.c

Settings.h

Settings.c

main.c

I2C2.h

I2C2.c

eeprom.h

Pour les define, je les mets dans chaque fichier (ceux que j'ai besoin) car si je le met pas, il me met une erreur de compilation. Par exemple mon "#define OK_BUTTON PORTCbits.RC5" est défini dans le main.c et dans Settings.C, si je le retire de settings, j'ai cette erreur de compil : Settings.c:318:29: error: use of undeclared identifier 'OK_BUTTON'

Peut-être que je l'ai mal fait ? Ou n'ai pas bien compris ?

[satinas]

Tu peux mettre les defines généraux comme _XTAL_FREQ et tout ce qui touche au hardware (leds, boutons, etc) dans un header main.h ou hardware.h, il sera inclus dans tous les sources qui en ont besoin. Si tu veux que ton source i2c soit indépendant du hardware, tu ajoutes au header hardware des defines pour déclarer les pins associées (ou pas).

La facilité serait comme tu l'as fait de mettre xc.h et les stdxxx.h dans un fichier .h pour ne pas les déclarer en début de chaque fichier .c, d'ailleurs là aussi tu as dupliqué. Je préfère les laisser uniquement en début des sources C pour indiquer quelles bibliothèques C sont utilisées.

Tout cela n'est pas figé, chacun ses gouts, l'essentiel est d'avoir unicité de l'information, bien que le C te préviendra s'il trouve un define déclaré 2 fois et de façon différente. Il est conseillé de mettre comme tu l'as fait un ifndef en début de header pour pouvoir les inclure plusieurs fois d'affilée s'ils figurent un peu partout, je préfère ne pas mettre ce ifndef, cela m'oblige justement à avoir des headers correctement construits qui seront inclus une fois max, sinon erreurs de compil.

Est ce que au démarrage toutes les données stockées en eeprom sont fausses, ou une seule l'est ?

[Stefox]

Oh ok ! Bon à savoir, ce sera mieux avec cette méthode, merci de l'astuce, ça me plaît bien !!!

Il y a 3 type de données en eeprom (Un code avec une date généré et stocker toute les 24h - Un SetPoint Brightness - Un Setpoint Temp) au démarrage, en cours d'exécution et au redémarrage, le code avec une date et le SetPoint Brightness semblent ok même après coupure !

Setpoint Temp démarre toujours lui avec 26 (D'où, pourquoi, comment, cela est peut être le souci..). Si je le modifie a 30 par exemple, mon LCD récupère bien 30 et cela a l'air de correspondre avec ma "régulation" de température. C'est uniquement si je coupe l'alimentation et que je la remet que la cette donnée (Setpoint Temp) se perd et redevient a 26 au lieu de 30 toute seule (Ma "régulation" revient sur 26 également).

[satinas]

Bonjour,
Il y a du monde dans ce programme. Je te fais des remarques sans avoir approfondi.
Le booléen ok/pb retourné par les différentes fonctions I2C manque de cohérence.
La taille de l'eeprom est 0x20000 octets. D'après sa doc j'aurais mis 0x50 et 0x51 pour les adresses I2C des 2 blocs 64k.
Pourquoi tu traites des pages de 64 octets alors qu'elle se programme par pages de 128 octets.
ClearBank_0() efface de 0 à 0X3FFF au delà de la zone réservée.
Où alors je ne suis pas encore réveillé

[Stefox]

Bonjour,

J'ai limité à 0x3FFF la mémoire car sinon c'est assez lent a clear et a parcourir, vu que j'enregistre 7 données (jour mois année (2 derniers chiffres), code (msb lsb) et un flag) ça me fait 6 ans de stockage environ ce qui est déjà bien plus qu'assez pour mes besoins

Ok pour l'adresse i2C 0x51 et non 58 et je mettrai 128 et non 64

Par contre pour le c'est bank je vois pas trop, pour moi elle efface jusque 0x3FFB (EEPROM_RESERVED_START), ça me semblait correct ?

[satinas]

J'ai parlé trop vite, c'est une eeprom, pas une flash
Je relis la doc et je reviens ...

Me voilà, sur une eeprom il n'est pas nécessaire d'effacer avant d'écrire.
il y a bien un buffer d'écriture de la taille d'une page. Avant écriture il contient les données contenues dans l'eeprom, je le suppose car pas lu explicitement. Pour une flash c'est différent.

L'eeprom écrit systématiquement des pages de 128 octets. Lorsque on lui envoie une adresse de début d'écriture, elle positionne le pointeur dans le buffer en conséquence (adr%128) et stocke tous les octets qu'on lui envoie. Si on arrive au bout du buffer elle remet le pointeur du buffer à 0. Si tu n'écris qu'un seul octet elle écrit la page qui le contient, mais les 127 autres octets de l'eeprom seront inchangés car ils sont présents dans le buffer.

Lors du ClearBank0() Tu écris tes 256 pages de 64 octets d'adresses 0x00000, 0X00040, 0x00080 ...0x03F80, 0x03FC0
car dans ton for() 0x03FC0 est inférieur à 0x3FFB
Lors de l'écriture de cette dernière page 0x03FC0 il met à 0 de 0x03FC0 à 0x03FFF car tu as envoyé 64 fois 0 dans la commande d'écriture.