Des hFF aléatoires dans la mémoire EEPROM.

[Superphénix]

Bonjour

J'ai quasiment finit mon projet à base de PIC18F2620, mais il reste un problème que je cherche à résoudre.
La carte sera soumise à des chocs plutôt violents et risque de perdre l'alimentation. Pour éviter de perdre une partie des donnés qu'on est censé récupéré à la fin, j'ai décidé d'écrire les données dans la mémoire EEPROM au fur à mesure. Pour ça le programme écrit un texte dans la mémoire EEPROM au début du programme et puis le complète au fur à mesure de l'exécution en ajoutant des valeurs mesuré sur un capteur (c'est dans une interruption qu'on appelle la fonction qui écrit les valeurs dans la EEPROM). Tout fonctionne correctement, sauf, à 2 endroits de la EEPROM où je retrouve des hFF à la place du texte. J'ai essayé de réduire le programme au maximum jusqu'à ce que ce bug disparaisse, mais à chaque fois que j'arrive à le faire disparaitre c'est après avoir enlevé du code qui n'a rien avoir avec l'écriture de la EEPROM.
Avant de poster un programme de 1000 lignes (ou 500 pour la version réduite), je tente de demander comme ça, au cas où il s'agit d'un problème courant du à une erreur de débutant récurrente ? Sinon je le posterai. Une idée ?

Il y a une ligne de texte dans la EEPROM qui est censé être comme ici :
T° apo : +28.5 °C
Et à la place j’obtiens ce texte :
T° apo :ÿ+28.5 °ÿ
(Le ÿ c'est hFF en ascii)

[satinas]

Salut,
Difficile de répondre, la première étape serait si ce n'est pas déjà le cas, de faire une fonction d'écriture avec vérification immédiate par lecture et comparaison. C'est ce que je fais toujours, sans trop ralentir l'appli car la lecture est très rapide. Avec ces fonctions, en cas d'erreur d'écriture, tu le sauras tout de suite par message d'erreur.
bool EepromWriteVerifyByte(adr, byte);
bool EepromWriteVerifyBuffer(adr, buf, size);
Il faut aussi un moyen de debug, port série par exemple, affichant tout ce que tu écris dans l'eeprom afin de vérifier que les données passées à la fonction d'écriture sont correctes.
Peut-être la séquence d'instructions ou les temps d'écriture ne sont pas respectés. Le flag IPEN est bien à 0 ?
Si le problème persiste c'est que le contenu de l'eeprom est détérioré à posteriori. Je n'ai pas le souvenir d'avoir écrit une eeprom depuis une routine d'interruption, cela me semble un peu risqué, bien que cela doit être possible.

[djviper16]

Bonjour,

Pour ma culture, pourquoi est-ce risqué d'écrire une EEPROM depuis une routine d'interruption ?

En cas d'avoir mal priorisé ses interruptions, et qu'une autre interruption vienne interrompre la routine de celle en cours ?

[satinas]

Bonjour,
Oui c'est le cas de figure qui pourrait se produire, mais comme la procédure d'écriture eeprom prévoit de faire GIE=0, elle empêche l'interruption de haute priorité de démarrer, puisque GIE et GIEH correspondent à un même bit. Ce que je voulais dire c'est que tant qu'on a pas lu le datasheet avec rigueur, il faut faire simple, car on ne maîtrise pas parfaitement la chose et ses écueils. D'autre part mettre des tempos dans des routines d'interruption n'est pas très conseillé, bien que là aussi c'est possible tant qu'on sait ce que l'on fait :)