Qu'est-ce qu'un checksum
Un calculateur moteur ne peut pas se permettre d'exécuter une mémoire abîmée. Une valeur erronée dans une cartographie d'injection ou dans une limite de sécurité peut détruire le moteur en quelques secondes de pleine charge. Les constructeurs ont donc prévu un mécanisme de vérification : la somme de contrôle, ou checksum.
Le principe
À côté de chaque zone de mémoire, le calculateur stocke une valeur calculée à partir du contenu de cette zone. L'idée est simple : au démarrage, il refait le calcul sur ce qu'il lit réellement, et compare au résultat enregistré.
- Les deux valeurs correspondent → la mémoire est réputée intacte, le calculateur démarre.
- Elles diffèrent → il en déduit une corruption, et refuse de fonctionner normalement.
Une somme de contrôle est donc, au sens strict, une valeur de taille fixe calculée sur un bloc de données pour détecter une altération : le récepteur recalcule et compare. C'est le même principe qui protège un fichier compressé ou une trame réseau.
Checksum, CRC : des robustesses différentes
Le calcul lui-même varie beaucoup selon le fabricant et la génération :
| Famille de contrôle | Ce que c'est | Robustesse |
|---|---|---|
| Somme simple (ADD8 / ADD16 / ADD32) | Addition des octets d'une zone | Faible : deux erreurs peuvent se compenser |
| CRC (16 ou 32 bits) | Division polynomiale du bloc | Élevée, sensible aux erreurs en rafale |
| Algorithme propriétaire | Variante constructeur non publiée | Variable |
Le CRC (Cyclic Redundancy Check) produit une valeur de contrôle nettement plus fiable qu'une simple addition, notamment face aux erreurs groupées. Un firmware embarque souvent plusieurs contrôles de natures différentes selon les zones. C'est précisément pour cette raison qu'un outil universel « qui corrige tout » n'existe pas : chaque famille demande son propre traitement.
Ce qui se passe quand la somme est incohérente
Dès qu'on modifie un seul octet — une case de cartographie, un limiteur, un seuil — la valeur enregistrée ne correspond plus au contenu. Écrire le fichier en l'état donne, selon le calculateur :
- L'outil de flashage refuse l'écriture. C'est le scénario le plus favorable : rien n'est cassé, on corrige et on recommence.
- Le calculateur passe en mode dégradé. Puissance limitée, voyant moteur allumé, défaut permanent en mémoire.
- Le moteur ne démarre plus du tout.
- Sur certaines familles, le calculateur devient inaccessible et impose un passage au banc, voire un dessoudage du microcontrôleur, pour être récupéré.
Une écriture avec un checksum incohérent est l'une des premières causes de calculateur mort en reprogrammation. Ce n'est pas une étape facultative de fin de traitement : c'est la condition pour que le fichier soit utilisable.
Plusieurs sommes dans un même fichier
Un fichier de calculateur ne contient presque jamais une seule somme de contrôle. On trouve couramment :
- une somme sur la zone programme,
- une ou plusieurs sommes sur la zone de données,
- parfois une somme par bloc de cartographies,
- sur les générations récentes, des mécanismes supplémentaires liés à la signature du logiciel.
Corriger « le » checksum d'un fichier veut donc dire : rétablir toutes les sommes concernées par la zone qu'on a touchée, avec l'algorithme propre à cette famille de calculateur.
Le CVN, un checksum remonté par l'OBD
La réglementation a fait du checksum un objet visible de l'extérieur. Le CVN (Calibration Verification Number) est une empreinte, typiquement un CRC32, que le calculateur calcule sur sa calibration et met à disposition par l'OBD. Associé au CAL ID (l'identifiant de version), il permet à un contrôle de vérifier que le logiciel embarqué correspond bien à une référence connue. Voir CAL ID et CVN.
Au-delà du simple checksum : la signature
Sur les calculateurs récents, la somme de contrôle ne fait plus tout. Un mécanisme de signature — un condensat de la mémoire chiffré avec une clé, vérifié au démarrage contre une clé publique stockée dans le calculateur — garantit non seulement l'intégrité mais aussi l'authenticité du logiciel. C'est le principe du démarrage sécurisé. Il ne relève plus de la même logique qu'une somme de contrôle et ne se recalcule pas librement. Voir signature RSA et secure boot.
Qui corrige, en pratique
C'est le point à bien comprendre, parce qu'il détermine votre façon de travailler.
Nous livrons le fichier modifié sans toucher aux sommes de contrôle. Ce n'est pas un oubli, c'est un choix technique délibéré :
- La plupart des outils de programmation corrigent eux-mêmes les sommes au moment de l'écriture. C'est leur rôle, et ils le font pour les familles qu'ils couvrent.
- Nous ne savons pas à l'avance quel outil vous utilisez, ni dans quelle version, ni comment il se comporte face à un fichier déjà corrigé.
- Un fichier corrigé en amont peut poser problème à un outil qui applique ensuite sa propre correction : la seconde passe travaille sur une base qui n'est plus celle qu'il attendait.
Livrer le fichier tel quel vous laisse maître de la chaîne : votre outil fait ce qu'il sait faire, dans l'ordre qu'il connaît.
Si votre outil ne corrige pas
Certains outils ne corrigent pas, ou pas sur toutes les familles. Dans ce cas, un correcteur de sommes de contrôle est mis à disposition : le fichier y passe avant écriture. La bonne séquence reste la même — lire le calculateur, archiver l'original, appliquer la modification, laisser l'outil (ou le correcteur) rétablir les sommes, puis écrire.
Le seul cas à éviter est la double correction : un fichier déjà corrigé auquel un outil applique une nouvelle passe. En cas de doute sur le comportement de votre outil, un essai sur un fichier de test tranche la question une bonne fois.
Voir aussi le rôle du calculateur, écrire sans risque et la famille EDC17.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
