Comment préparer un fichier 1B pour l'utiliser dans le générateur de code FSC

Voici quelques conseils sur la façon de préparer correctement fichier 1B à utiliser dans le FSC code generator pour éviter les erreurs 0xD1 ( "version après create () = 0xD1"). Prendre plaisir!

Quelqu'un sait comment résoudre "la version après l'erreur create () = 0xD1"?

Le bloc d'octets que vous devez extraire du fichier generalPersistencyData_DiagnosticSWTController commence par la séquence d'octets suivante:

01 01 00 1B
Le fichier generalPersistencyData_DiagnosticSWTController se trouve dans / mnt / HBpersistence / normal / sur le système de fichiers QNX.

Vous pouvez également utiliser le fichier debug data03, situé dans le dossier / mnt / hbdebug /.

La séquence 01 01 00 1B commence au décalage 0x270. Cependant, il ya une différence dans la façon dont vous calculez la longueur de la séquence 1B, selon le fichier que vous avez téléchargé à partir de l'ordinateur QNX via le service FTP.
La longueur des octets que vous devez extraire des fichiers generalPersistencyData_DiagnosticSWTController ou data03 est indiquée par les octets précédant la séquence 01 01 00 1B.

Dans le fichier generalPersistencyData_DiagnosticSWTController, la longueur est indiquée par 4 octets avant la séquence 01 01 00 1B d'octets. Pour le fichier data03, la longueur des octets à extraire du fichier data03 est indiquée par 2 octets qui précèdent la séquence 01 01 00 1B.

Par exemple, si vous ouvrez le généralPersistencyData_DiagnosticSWTController dans un éditeur Hex (tel que HxD) et sautez au décalage 0x270, vous pouvez trouver la séquence suivante d'octets qui précèdent la séquence 01 01 00 1B:

3F 01 00 00
Ce sont les quatre octets qui définissent le nombre d'octets que vous devez couper à partir du fichier generalPersistencyData_DiagnosticSWTController pour préparer le fichier hexadécimal 1B correct à utiliser avec l'FSC tool.

Le système d'info-divertissement CIC IVI est basé sur le processeur Renesas SH7785 (ancien Hitachi). Ce processeur est basé sur l'architecture RISC et prend en charge la séquence d'octets LE (LittleEndian) et BE (BigEndian). Pour l'implémentation de CIC, nous avons l'architecture LE. Cela signifie que nous devons échanger l'ordre des octets pour récupérer l'ordre correct des octets.

Pour notre séquence

3F 01 00 00
L'ordre approprié pour calculer la longueur sera:

00 00 01 3F
ou simplement

13F
Comme les nombres sont hexadécimaux, la valeur décimale est 319 (parce que 13Fh = 319d). En d'autres termes, cela signifie que pour recevoir le fichier 1B correct, nous devons couper 319 octets de la position 0x270 dans le fichier generalPersistencyData_DiagnosticSWTController.

Ce nombre d'octets, la longueur du bloc d'octets que nous devons extraire, est une chose importante. Si vous extrayez un nombre incorrect d'octets, le fichier 1B résultant produira un convolutuion incorrect dans l'outil FSC et donc l'erreur D1.

Par exemple, si vous voyez que dans votre fichier generalPersistencyData_DiagnosticSWTController vous avez 4 octets différents avant le 01 01 00 1B, vous devez calculer la taille en fonction de cette séquence dans votre fichier. En effet, le gars dont j'ai appris ce truc, a dû couper 322 octets.

De plus, si vous utilisez le fichier data03, veuillez noter que la longueur doit être calculée en fonction de deux octets précédant la séquence 01 01 00 1B. Par exemple, si vous avez:

42 01
Séquence précédemment, comme dans ce cas de MrPerfekt, les octets de retour vous donneront le numéro:

01 42
ou simplement

142
Conversion 142 dans le système décimal vous trouvez que vous devez couper 322 octets (car 142h = 322d)

Si vous coupez 320 octets où vous avez dû couper 319, vous recevrez l'erreur 0xD1 lorsque vous utilisez l'outil FSC pour votre fichier HEX:

Version après create () = 0xD1
Voici une courte instruction sur la coupe de la bonne quantité d'octets à partir du fichier generalPersistencyData_DiagnosticSWTController.

Télécharger un éditeur hexadécimal tel que HxD (WinHEX est encore plus bon mais pas nécessaire pour une telle opération simple).
Appuyez sur Ctrl + E pour sélectionner un bloc d'octets.
Dans la zone d'édition Start-offset, entrez le début du bloc (numéro de décalage): 270.
Dans la zone d'édition Longueur entrez la taille du bloc: 13F. L'outil sélectionne automatiquement les 319 octets désirés pour vous.
Appuyez sur Ctrl + C pour copier le bloc sélectionné.
Maintenant, appuyez sur Ctrl + N pour créer un nouveau fichier et collé le bloc copié en lui en appuyant sur Ctrl + V.
Enregistrez le fichier hexadécimal créé en utilisant le modèle de nommage suivant: XXNNNNN_001B0001.hex (ici XXNNNNN sont les 7 derniers symboles de votre numéro VIN).
Si vous ne vous souvenez pas de votre NIV, ces chiffres sont exactement là dans le fichier généralPersistencyData_DiagnosticSWTController au décalage 0x2E.
Vous êtes prêt.

Maintenant, utilisez la commande:

Fsc XXNNNNN_001B0001.hex APP_ID UPGRADE_INDEX
APP_ID est le nombre hexadécimal qui définit la région de la carte. Par exemple, pour l'Europe APP_ID = 0x28.

UPGRADE_INDEX est le numéro hexadécimal qui définit l'édition des cartes. En règle générale, l'index de mise à niveau est augmenté en incrément de 1 octet de version en version. Par exemple, la première édition pour l'année en cours (2016-1) a l'indice de 0x0B, la deuxième édition (2016-2) est, donc, 0x0C. Si vous ne vous souciez pas de spécifier l'index 0x0D à l'avenir, lors de la mise à niveau vers 2017-1, vous pouvez définir l'index à 0xFF. Le masque de bits résultant vous permettra de mettre à niveau les cartes à l'avenir sans devoir spécifier le code FSC.

Citation de http://f30.bimmerpost.com/; Merci pour celui qui partagent toutes les informations ci-dessus.