Change language of 19G488 or 19C112 Bluetooth-Module

[Go4IT]

I know the language is specified by pre-last char of partnumber, e.g. 19C112-A* for English, 19C112-B* for German, 19C112-D for Spain, and so on.
I also know that mentioned modules can only keep one single language (first multilanguage module was 14D212) and usually it is not possible to change it.

BUT - hey, as we are here on a hacker forum, let's see if there is really no way of doing it?! Who want's to assist?

My first interest is of the update files for the module. I attached the latest available version of it. They are for "Sound & Connect" modules only, so only applicable to 19C112. Also there where no public updates for 19G488 available (as far as i know...).
All 19C112 are equiped with an USB-Port, where a usual MINI- or MICRO-USB cable would fit, to install the update. Only place all files from the ZIP onto a FAT32 formatted stick and put it into the USB plug of the glovebox. Turn on the radio and it should show "Update in progress" or something like that.

In the ZIP you find files for various languages (look at pre-last char). The module will only fetch the "right one" for itself. So if it is an *-B* (German) it will only use the 8M5T-14D511-BV.* files. (Note that "14D511" is the partnumber of the software, not the hardware).

There are two files for each language, both about 7 MB in size:

• 8M5T-14D511-BV.vbf
• 8M5T-14D511-BV.bvc

Both files are identical and in Volvo-Binary-Format (VBF). I guess the internal bootloader of the module would fetch the "*.bvc" files and the the vbf is for update via CAN.

Let's take a look at the interesting parts of the header:

Code: Select all

       sw_part_number = "8M5T-14D511-BV";
       ecu_address = 0x772;

Next i extracted the binary part of the VBF (did it manually as it would not load with the VBF-Tool i have). It contains the partnumber several times and compared to another language the first 0x382B00 bytes are very similar, expect of some bytes representing the language itself. From address 0x382B1C onwards the files differ totally.

As for any update we should remind that there comes a SBL first and so we read:
"SBL-MCU V 4.700 30-07-12 RX-42 HW60 (c) Nokia"
This tells us that the update would only apply on modules of type "RX-42" and HW60 onwards. On the label of my module i find:

8M5T-19C112-BN_up-label.jpg

[DGAlexandru]

They also work for 19G488 as long as it has an USB port (= it is also a stereo module, HW 42).
The update file contains more update files inside - this is why it isn't recognised by VBF Loader (or UC DS).

If you use a HEX compare software you will see that two files have almost the same content, less the last "update file" which is for language recognition and it also contains the voice messages.

I tryed to use the English version over a German SRM by renaming the file and also the "update files" from within, with checksums recalculated, but no luck - it fails after some time - I think when it gets to the last one.

Another approach would be to connect to the CPU by JTAG and doing whats needed from there.

I even swapped the 3 Flash chips - the modules were still asking for their original language file for update even if they were working with swapped language.

[Go4IT]

I tried to look into the data structure of the update file (for example i used "8M5T-14D511-BV.vbf" here, extracted binary part).
There are several blocks inside this single file, all starting with a 0x80 length header. This is what i found out about it so far:

Code: Select all

 2 Byte = ?            # 
 6 Byte = Magic + 0x00 # "NSWUP"
 2 Byte = 0x0100       # ???
 2 Byte = 0x0200       # Counter 0x0200, 0x0201, 0x0202, ...
 4 Byte = ?            #
 4 Byte = ?            #
 4 Byte = Data length  # Size of payload after header-block
64 Byte = Description  # TEXT: Description of content ("SBL-BTH V 4.700 30-07-12 RX-42 HW60 (c) Nokia")
24 Byte = Partnumber   # TEXT: Software-Partnumber ("8M5T-14D511-BV")
 2 Byte = Data checksum # CRC16-CCITT checksum of payload data
 4 Byte = ?            #
 2 Byte = ?            #
 4 Byte = Data length  # Size of payload after header-block
 4 Byte = ?            #

There are 17 such blocks in the file. The USB-Updater running on the module would load the full file into it's RAM (it got a 8 MByte external SDRAM) and may execute the SBL (or maybe not and the SBL is only for CAN-Update... don't know).

[Go4IT]

The language-dependent part seem to start at offset 0x00382B08 in the file. This is the start of the NWSUP part "3706_Ded_10.81_Full.pck". No idea what kind of dataformat this may be. I could be a simple packed WAVE file, but also some really arbitrary DSP-stuff. Also speech-recognition would highly differ from speech-output and i do not expect to find whole words or sentances inside, just fragments of verbs and vowels, like any other speech synthesizer does.

[Go4IT]

Maybe it would be helpfull to disassemble the firmware? It uses little-endian CR16C Mnemonic. I found a plugin for IDA-Pro here https://github.com/krater/CR16C-IDA-Pro-Plugin and also some informations about an emulation https://www.isystem.com/downloads/winID ... CR16C.html

[Go4IT]

I even swapped the 3 Flash chips - the modules were still asking for their original language file for update even if they were working with swapped language.

Means there is some kind of hardware-encoding which tells the module of which kind it is? Hmm... there is an external EEPROM on the module also, but it will be repopulated if erased (see "(23)"):

bt-module_parts_top.jpg

The 2 MByte Flash "(2)" contains the bootloader and firmware. It's /CE is connected to CS0 of the MPU. It's starting address is 0x00400000 (because ENV0, ENV1 select ERE16L mode of MPU).

[DGAlexandru]

I don't think the SBL files are used for CAN programming.
Other than that, I found the same things and more (back in 2012 and then a second try in 2014):

File: 8M5T-14D511-AT.vbf
From beginning till 0x0B6A02 we have:
VBF standard header
0x0003B7: SBL for MCU
0x040033: SBL for BlueTooth (BTH)
0x042061: SBL for DSP
0x046983: PBL for MCU

Searching for "NSWUP" or "4E 53 57 55 50" in hex will reveal each block that contains instructions on what to do.
Also this keyword is hardcoded in SBL-MCU "file" and also in this "PBL" and the next PBL which is contained by M29W160 flash chip.

dump: M29W160ET_511-DR-DT.bin - contents of M29W160ET flash chip of an 511DR hardware SRM with DT software.

Code: Select all

File	    Start Add    End Add
dump      - 0x000000 ... 0x0044BF ... no ideea :) 
dump      - 0x0044C0 ... 0x00FFFF ... full with FF

14C511-AT - 0x0B6A81 ... 0x126A801
dump      - 0x010000 ... 0x07FFFF

14C511-AT - 0x126B01 ... 0x296B00
dump      - 0x080000 ... 0x1EFFFF

dump: M29W800_511-DR-DT_swap.bin - contents of M29W800 flash chip of an 511DR hardware SRM with DT software. I had to swap bytes in order to have its contents like the update file.
dump: M29W800_511-DR-DT_2_swap.bin like M29W800_511-DR-DT_swap.bin but after I added a phone - a SonyEricsson W910i

Code: Select all

File	    Start Add    End Add
14C511-AT - 0x296C03 ... 0x29AC06 ... without 2 bytes for checksum that are present every 0x2000 bytes
dump	  - 0x000000 ... 0x003FFF

dump	  - 0x004000 ... 0x007FFF ... contents that gets changed when you add / remove a phone; also maybe other configuration data

14C511-AT - 0x29AC07 ... 0x2A4C10 ... without 2 bytes for checksum that are present every 0x2000 bytes
dump	  - 0x008000 ... 0x011FFF

dump	  - 0x12000 ... 0x01FFFF ... full with FF

14C511-AT - 0x2A4C11 ... 0x33CCA8 ... without 2 bytes for checksum that are present every 0x2000 bytes
dump	  - 0x020000 ... 0x0B7FFF

dump	  - 0x0B8000 ... 0x0B9FFF ... full with FF

14C511-AT - 0x33CCA9 ... 0x382CEE ... without 2 bytes for checksum that are present every 0x2000 bytes
dump	  - 0x0BA000 ... 0x0FFFFF

From 0x382CEF till the end of 14C511-AT file I think we have the instructions to write the M29W640GL flash chip.
I couldn't read M29W640GL flash chip as I don't have a TSOP56 adapter.