Originally Posted by GARFIgo

Someone knows how solve “version after create () = 0x1D” error?

The block of bytes that you must extract from the
generalPersistencyData_DiagnosticSWTController file starts with the following sequence
of bytes:

Quote:

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:

Quote:

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

Quote:

3F 01 00 00
the proper order to compute the length will be:

Quote:

00 00 01 3F
or simply

Quote:

13F
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
(MrPerfekt), 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:

Quote:

42 01
sequence before, like in that case of MrPerfekt, reverting bytes will give you the
number:

Quote:

01 42
or simply

Quote:

142
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:

Quote:

version after create() = 0xD1

Here is a short instruction on cutting the proper amount of bytes from the
generalPersistencyData_DiagnosticSWTController file.

1. Download a hex editor such as HxD (WinHEX is even more good but not necessary
for such a simple operation).
2. Press Ctrl+E to select a block of bytes.
3. In the Start-offset edit box enter the start of the block (offset number): 270.
4. In the Length edit box enter the size of block: 13F. The tool will automatically select
the desired 319 bytes for you.
5. Press Ctrl+C to copy the selected block.
6. Now press Ctrl+N to create a new file and pasted the copied block into it by pressing
Ctrl+V.
7. 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:

Quote:

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.