How to prepare 1B file for using in FSC code generator
Here are some tips of how to properly prepare 1B file for using in FSC code generator to avoid 0xD1 errors (“version after create () = 0xD1”). Enjoy!
|Someone knows how to solve “version after create () = 0xD1” error?|
The block of bytes that you must extract from the generalPersistencyData_DiagnosticSWTController file starts with the following sequence of bytes:
|01 01 00 1B|
The generalPersistencyData_DiagnosticSWTController file can be found in /mnt/HBpersistence/normal/ on the QNX file system.
Alternatively, you may also use the debug data03 file, located in the /mnt/hbdebug/ folder.
The 01 01 00 1B sequence starts at the 0x270 offset. However, there is a difference in how you compute the length of 1B sequence, depending on what file you have downloaded from the QNX computer via FTP service.
The length of bytes that you must extract from generalPersistencyData_DiagnosticSWTController or data03 files is indicated by the bytes prepending the 01 01 00 1B sequence.
In the generalPersistencyData_DiagnosticSWTController file the length is indicated by 4 bytes that go before the 01 01 00 1B sequence of bytes. For the data03 file the length of bytes to extract from the data03 file is indicated by 2 bytes that prepend the 01 01 00 1B sequence.
For example, if you open the generalPersistencyData_DiagnosticSWTController in a Hex editor (such as HxD) and jump to the offset 0x270, you may find the following sequence of bytes that prepend the 01 01 00 1B sequence:
|3F 01 00 00|
These are the four bytes that define how many bytes you must cut from the generalPersistencyData_DiagnosticSWTController file to prepare the correct 1B hexadecimal file for using with the FSC tool.
The CIC IVI infotainment system is based on the Renesas SH7785 (former Hitachi) processor. This processor is based on RISC architecture and supports both LE (LittleEndian) and BE (BigEndian) byte sequence. For the CIC implementation we have the LE architecture. That means we need to swap order of bytes to retrieve the correct order of bytes.
For our sequence
|3F 01 00 00|
the proper order to compute the length will be:
|00 00 01 3F|
Since the numbers are hexadecimal, the decimal value is 319 (because 13Fh = 319d). In other words, this means that to receive the correct 1B file, we must cut 319 bytes from the position 0x270 in the generalPersistencyData_DiagnosticSWTController file.
This number of bytes, the length of the byte block that we need to extract, is an important thing. If you extract incorrect number of bytes, the resulting 1B file will produce incorrect convolutuion in the FSC tool and hence the D1 error.
For example, if you see that in your generalPersistencyData_DiagnosticSWTController file you have different 4 bytes before the 01 01 00 1B, you must calculate the size based on this sequence in your file. Indeed, the guy from whom I learned this stuff, had to cut 322 bytes.
Also, if you use the data03 file, please note that length must be calculated based on two bytes prepending the 01 01 00 1B sequence. For example, if you have:
sequence before, like in that case of MrPerfekt, reverting bytes will give you the number:
Converting 142 into the decimal system you find that you need to cut 322 bytes (because 142h = 322d)
If you cut 320 bytes where you had to cut 319, you will receive the 0xD1 error when using FSC tool for your HEX file:
|version after create() = 0xD1|
Here is a short instruction on cutting the proper amount of bytes from the generalPersistencyData_DiagnosticSWTController file.
- Download a hex editor such as HxD (WinHEX is even more good but not necessary for such a simple operation).
- Press Ctrl+E to select a block of bytes.
- In the Start-offset edit box enter the start of the block (offset number): 270.
- In the Length edit box enter the size of block: 13F. The tool will automatically select the desired 319 bytes for you.
- Press Ctrl+C to copy the selected block.
- Now press Ctrl+N to create a new file and pasted the copied block into it by pressing Ctrl+V.
- Save the created hexadecimal file using the following naming template: XXNNNNN_001B0001.hex (here XXNNNNN are the last 7 symbols of your VIN number).
If you can’t remember your VIN, these figures are right there in the generalPersistencyData_DiagnosticSWTController file at the 0x2E offset.
You are all set.
Now use the command:
|fsc XXNNNNN_001B0001.hex APP_ID UPGRADE_INDEX|
APP_ID is the hexadecimal number that defines the region of the map. For example, for Europe APP_ID = 0x28.
UPGRADE_INDEX is the hex number that defines edition of maps. Typically, upgrade index is increased in 1 byte increment from version to version. For example, the first edition for the current year (2016-1) has the index of 0x0B, the second edition (2016-2) is, hence, 0x0C. If you don’t care specifying the 0x0D index in the future, when upgrading to 2017-1, you might want to set the index to 0xFF. Resulting bit mask will allow you to upgrade the maps in the future without having to specify the FSC code.
Quoted from http://f30.bimmerpost.com/; Thanks for the one who share all info above.