Alter memory program for a CSR BC57E687C BlueCore5 firmware

[satoshi]

I paid a custom firmware for a CSR Bluetooth Chip: BC57E687C and our supplier decided to stop manufacturing the module, all of a sudden. They never shared the software with us. We are thinking about overcoming this problem by integrating the BC57E687C into our PCB as we were able to extract the customised firmware (firmware link) with BlueFlash from CSR but we are not able to alter the Bluetooth Address. If we alter the Bluetooth Address using PSTool, the CSR won't boot up. The BC57E687C implements a Harvard architecture and I am able to see the bluetooth address in the memory data (XDV file) from the firmware so I have tried to edit the Bluetooth address directly on the XDV file and download it into the BC57E687C. The flash contains exactly the expected data but when I turn the MCU on, the section of the flash where the Bluetooth Address is located is wiped out and the Bluetooth won't boot up. The MCU detects the modification somehow.

I discovered the XDV file has three well differentiated sectors at @000100, @002000 and @004100. I have extracted the firmware from four modules and the sections @000100 and @004100 from the XDV are equal. They only differ on the @002000, this section is precisely where the Bluetooth Address is and the section that gets erased when downloading a modified XDV. The program data (XPV) is equal for all the extracted firmwares and I can flash any of the firmwares in any module interchangeably without any issues.

I tried to analyse if there is any checksum or CRC in the whole flash or if there's any check per sections but I can't seem to find any pattern.

I'm trying to change the Bluetooth address 009a e0c0 0043 001d (located at @0028e0 and @0028fb) from the firmware attached to the addrss 009a e073 0043 001d (a random modification).

There is so little information from CSR and I think it is especially true now that CSR was acquired by Qualcom. Maybe someone here has experience with the now old CSR BlueCore5  and can help me out. This component is part of one of our products and we need to keep producing it at least until we can develop our own firmware, but that will take time.

[TomS_]

Sounds like there may be some kind of checksum involved in the block of data where the MAC address is contained. If the checksum doesnt match then perhaps it wipes out that data and it needs to be reloaded another way?

How you will figure out the checksum algorithm and where the checksum is stored etc may not be easy.

Perhaps have discussions with the manufacturer about this and see if they are willing to help.