Les formats de fichier : BIN, Intel HEX, S-record
Un même contenu de mémoire peut voyager sous plusieurs formats. Le reprogrammateur en croise trois en permanence : l'image binaire brute (BIN), et deux formats texte qui portent leurs adresses, l'Intel HEX et le S-record de Motorola. Confondre les trois, ou convertir de l'un à l'autre sans précaution, suffit à décaler tout un fichier.
Le BIN : une image brute
Un fichier .bin est une image mémoire brute : un octet du fichier correspond à un octet de la mémoire, dans l'ordre, sans en-tête ni annotation. C'est le format d'échange standard du fileservice, parce qu'il est simple et universel. Son revers : il est opaque. Rien, dans un .bin, ne dit où commence une cartographie, quelle est l'adresse de base, ni ce que vaut tel octet. Sans fichier de définition — un DAMOS, un A2L ou un mappack — un .bin n'est qu'une suite d'octets. C'est justement le rôle de ces définitions : donner un sens à l'image brute. Voir repérer les zones de calibration.
Un .bin est contigu : il couvre une plage mémoire d'un bout à l'autre, y compris les trous non programmés, qui apparaissent typiquement remplis d'octets 0xFF — l'état d'une flash effacée. Sa taille correspond à la région lue : 512 ko, 2 Mo, 4 Mo selon ce que l'outil a extrait et selon le mode, OBD, bench ou boot. Voir OBD, bench, boot et mémoire interne ou externe.
Intel HEX : du texte, avec des adresses
L'Intel HEX est un format ASCII : on peut l'ouvrir dans un simple éditeur de texte. Il est fait d'enregistrements, un par ligne, chacun commençant par le caractère deux-points. Un enregistrement se lit toujours dans le même ordre : nombre d'octets de données, adresse sur 16 bits, type d'enregistrement, données, puis une somme de contrôle de ligne.
Les types d'enregistrement à connaître : 00 = données ; 01 = fin de fichier ; 02 = Extended Segment Address ; 04 = Extended Linear Address ; 03 et 05 portent une adresse de démarrage. Le point délicat est le champ d'adresse sur 16 bits : à lui seul il ne dépasse pas 64 ko. Au-delà, le format s'appuie sur les enregistrements 02 et 04, qui posent une adresse de base haute à laquelle s'ajoutent les adresses 16 bits qui suivent. Perdre de vue cette base est la première cause d'erreur en conversion.
S-record : l'équivalent Motorola
Le S-record (extensions .s19, .srec, .mot), créé par Motorola au milieu des années 1970, répond au même besoin : transporter de l'information binaire sous forme de texte hexadécimal. Chaque ligne commence par la lettre S suivie d'un chiffre qui donne son rôle :
| Type | Rôle |
|---|---|
| S0 | en-tête / commentaire |
| S1 / S2 / S3 | données à adresse 16 / 24 / 32 bits |
| S5 / S6 | compte d'enregistrements |
| S7 / S8 / S9 | fin, avec l'adresse de démarrage (32 / 24 / 16 bits) |
Le choix S1/S2/S3 dépend de la largeur d'adresse nécessaire : un microcontrôleur dont la flash vit à 0x80000000 utilise du S3 (32 bits). Comme l'Intel HEX, chaque ligne se termine par une somme de contrôle qui ne protège que cette ligne : c'est un contrôle de transport, à ne pas confondre avec le checksum du firmware que vérifie le calculateur. Voir qu'est-ce qu'un checksum.
Les reconnaître d'un coup d'œil
- BIN : ouvert dans un éditeur de texte, illisible ; dans un éditeur hexadécimal, on voit directement la structure.
- Intel HEX : des lignes de texte commençant toutes par deux-points.
- S-record : des lignes de texte commençant par S0, S1, S2 ou S3.
BIN sert d'échange dans le fileservice ; HEX et S-record servent surtout à la programmation de microcontrôleurs (production, programmateurs de puce), et se rencontrent aussi en sortie de certains outils. Une nuance de vocabulaire piège les débutants : l'extension .hex ne garantit pas un Intel HEX. Certains outils appellent ainsi un simple vidage hexadécimal en texte, sans enregistrement structuré ni adresses — une représentation lisible d'un .bin, pas un format adressé. À l'inverse, un contenu exporté en Intel HEX ou en S-record occupe environ deux fois plus de place qu'en binaire, chaque octet y étant écrit sous forme de deux caractères ASCII, plus la ponctuation d'enregistrement. D'où un réflexe simple : devant un fichier douteux, on l'ouvre dans un éditeur de texte et on regarde la première ligne avant de décider ce qu'il est.
Convertir sans décaler : les pièges
Passer d'un format texte adressé à un .bin, ou l'inverse, est courant — mais trois pièges reviennent :
- L'adresse de base. Un HEX ou un S-record portent leurs adresses ; un .bin, non. Convertir un S3 en .bin oblige à décider à quelle adresse de base commence l'image. Se tromper d'offset décale tout le fichier : on croit éditer une cartographie, on écrit à côté.
- Les trous. Les formats texte sont souvent épars : ils ne décrivent que les régions réellement programmées. Un .bin, lui, est plein. La conversion doit combler les trous, en général avec 0xFF. Une mauvaise valeur de remplissage, ou une taille finale erronée, décale la suite.
- L'ordre des octets. Le format ne dit pas comment interpréter un mot de 16 ou 32 bits : cet endianness est affaire de définition — l'A2L le précise dans son RECORD_LAYOUT —, pas du conteneur de transport.
Règle de métier : une conversion se vérifie. On confirme la taille attendue, on contrôle que les régions connues (bootloader, calibration) tombent aux bonnes adresses, et que le fichier reste cohérent avec ce que le calculateur attend. C'est le même sérieux qu'à l'écriture. À noter que les fichiers slave, eux, ajoutent encore une couche de chiffrement par-dessus le format brut.
Voir aussi les fichiers de définition, repérer les zones de calibration et les conteneurs constructeur.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
