Moteur qui refuse de démarrer après flash : checksum et contrôle d'intégrité
L'écriture est annoncée « réussie ». On repose le calculateur, contact, on lance le démarreur… et rien. Le moteur vire mais ne part pas, ou il part et se met aussitôt en sécurité. À la lecture des défauts, un code revient : P0601 — Internal Control Module Memory Check Sum Error. Le fichier a bel et bien été écrit, et pourtant le calculateur le refuse. C'est un grand classique après une modification de contenu.
Diagnostic
Un calculateur ne fait pas confiance aveuglément à sa propre mémoire. À chaque démarrage, il vérifie des sommes de contrôle — des checksums — calculées sur ses zones de calibration et de programme. Chaque zone porte une sorte de sceau : une valeur (somme ou CRC) rangée dans le fichier lui-même. Si l'on modifie le contenu sans recalculer ce sceau, la vérification échoue : le calculateur sait que « quelque chose a changé » et refuse d'exécuter la calibration. Résultat : pas de démarrage, mode dégradé, ou P0601.
Pourquoi ces contrôles existent-ils ? Pour plusieurs raisons cumulées :
- intégrité des données : détecter une mémoire corrompue par du bruit électrique, un vieillissement, une écriture incomplète ;
- qualité de fabrication : vérifier que le bon logiciel a été flashé en usine ;
- détection de modification : repérer une calibration altérée ;
- sécurité de fonctionnement : ne pas laisser tourner un moteur sur des données douteuses.
Les calculateurs modernes ne portent pas un seul checksum. Un MED17, un MG1 ou un MD1 en ont plusieurs, couvrant séparément des zones différentes — la zone programme et la zone de données ne sont pas scellées ensemble. Les plus récents ajoutent par-dessus une signature cryptographique (type RSA). Il existe aussi un CVN (Calibration Verification Number) exposé au diagnostic, que les contrôles antipollution peuvent lire : il doit rester cohérent avec la calibration réellement présente.
Un checksum se recalcule. Une signature cryptographique, non — elle exige une clé privée qu'on n'a pas. D'où l'importance de préserver les zones signées telles quelles.
Résolution
La plupart des outils de reprogrammation appliquent automatiquement la correction de checksum pour les familles qu'ils supportent (on lit souvent « checksum by tool »). Le cas concret du P0601 vient donc en général d'un fichier édité en dehors de l'outil — un éditeur hexadécimal, un patch manuel — et réécrit sans correction. La marche à suivre :
- reprendre le fichier, corriger les checksums pour ce calculateur précis, puis réécrire ;
- si la zone modifiée est signée cryptographiquement, on ne peut pas forger la signature : on travaille uniquement là où c'est permis, en gardant la structure signée intacte — on ne cherche pas à la casser (voir calculateur verrouillé d'usine) ;
- après correction, on relit et on compare pour confirmer que le calculateur accepte enfin la calibration (voir vérifier après écriture).
Un P0601 qui persiste même après réécriture d'un original propre ne vient plus du checksum : il oriente vers une écriture partielle (flash interrompu) ou une mauvaise version de fichier par rapport au matériel réel. Le réflexe sûr : réécrire un original connu-bon adapté à l'exact numéro matériel, vérifier que le moteur démarre, puis seulement réappliquer les modifications avec correction.
Ce qu'on en retient
- « Écriture réussie » ne veut pas dire « fichier accepté » : le dernier mot appartient au calculateur, au démarrage, via ses contrôles d'intégrité.
- La correction de checksum est obligatoire après toute modification de contenu ; c'est le rôle de l'outil pour les familles supportées.
- Une signature n'est pas un checksum : c'est un mur, on le respecte.
- Un P0601 juste après une intervention se relit à la lumière du code P3028 après intervention logicielle : intégrité d'abord, adaptation ensuite.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
