La mémoire flash en fin de vie : perte de rétention, bits qui basculent et ECC

Une mémoire flash ne prévient jamais. Elle tient dix, quinze, vingt ans sans broncher — puis un matin, un seul bit bascule, le checksum ne tombe plus juste, et le calculateur refuse de démarrer. Ce n’est pas un « bug logiciel » : c’est du silicium qui a atteint sa limite physique. Autant savoir comment il y arrive.

Comment une flash oublie

Une cellule flash stocke l’information sous forme de charge piégée dans une grille flottante, isolée. Cet isolant n’est pas parfait : la charge fuit, très lentement. Les ordres de grandeur annoncés par les fabricants :

• une rétention de données typiquement garantie une vingtaine d’années à 55 °C ;
• une endurance de l’ordre de 100 000 cycles d’effacement/écriture pour de la NOR.

Deux facteurs accélèrent la fuite : le nombre de cycles subis — chaque effacement use l’oxyde — et la TEMPÉRATURE. Or un calculateur vit au chaud, parfois posé sur le moteur. L’EEPROM, qui stocke adaptations et compteurs réécrits en permanence, s’use encore plus vite que la flash programme. L’automobile embarque surtout de la flash NOR ou la flash intégrée au microcontrôleur, réputées pour leur rétention ; la NAND, plus dense mais plus capricieuse, se rencontre surtout sur les gros calculateurs multimédia, pas sur la gestion moteur.

Ce que ça donne comme pannes

• Checksum ou CRC faux au démarrage : le boîtier se déclare muet plutôt que de tourner sur un contenu douteux (voir calculateur muet après écriture).
• Un bit qui saute dans un octet de calibration : comportement aberrant, valeur qui n’a plus aucun sens physique.
• Une cellule d’EEPROM figée : une adaptation qui ne se met plus à jour, un compteur bloqué.
• Des pannes progressives, parfois « réparées » par une simple réécriture… le temps que la cellule refuse pour de bon.

L’ECC : un filet, pas un miracle

Beaucoup de mémoires embarquent un code correcteur d’erreurs. Il rattrape typiquement un bit erroné par mot et en détecte deux. C’est précieux — mais c’est aussi un cache-misère : tant que l’ECC corrige, l’usure avance sans qu’on la voie. Le jour où une deuxième erreur apparaît dans le même mot, la correction échoue, et la panne surgit d’un coup, sans préavis.

Diagnostiquer la mémoire

• Lire, puis relire : une lecture qui varie d’une fois sur l’autre trahit une cellule instable.
• Lire à la tension nominale, plusieurs fois : une cellule marginale peut renvoyer des valeurs différentes selon la tension d’alimentation, ce qui trahit la faiblesse mais fausse aussi la sauvegarde.
• Comparer à un dump sain connu : les octets qui divergent pointent la zone fatiguée.
• TOUJOURS garder un dump de référence sain, horodaté, AVANT la moindre écriture : c’est votre filet et votre traçabilité.
• Distinguer la flash programme, la calibration, de l’EEPROM, les adaptations : ce ne sont ni les mêmes contenus ni les mêmes usures (voir la carte mémoire d’un calculateur).
• Ne pas confondre une flash réellement usée avec un simple checksum faux consécutif à une écriture mal terminée : le second se corrige au clavier, la première non.

Ce qu’on peut faire

• Réécrire un contenu SAIN et vérifié — le bon dump — et reprovisionner l’EEPROM tant qu’elle est encore inscriptible.
• Quand la puce est vraiment usée, il n’y a pas de miracle : remplacement du composant et retransfert de l’identité et des données propres au véhicule.

L’ECC te cache l’usure jusqu’au tout dernier bit : quand la flash lâche, ce n’est pas un logiciel capricieux, c’est du silicium fatigué — et ça, ça se remplace.

Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.