?

Log in

No account? Create an account
entries friends calendar profile Previous Previous Next Next
How I unbricked CMU in my Mazda - Царапающий лбом скрижали времён
Mostly Harmless
yms
yms
How I unbricked CMU in my Mazda
(Note: the Russian version is here.)

What happened
Several months ago, I decided to upgrade the firmware in the CMU (Connectivity Master Unit, the infotainment computer) in my Mazda 3 (2014). I already did it at least two times before, quite successfully. As you may know if you did it too, the firmware package consists of two files, names ending with ..._failsafe.up and ..._reinstall.up, which are copied to a USB drive to start the upgrade process. The main part of the firmware is in the 2Gb reinstall file, the smaller failsafe part contains some code controlling the upgrade process including bootloader, progress indicator, etc. When I upgrade, I usually launch both of these files, failsafe first. This time, I upgraded from EU 56.00.513B to EU 59.00.443C version; I decided to launch only the reinstall part after having read somewhere that it's not mandatory to upgrade failsafe each time. When I ran reinstall, after some time it said, "Failed to validate package certificate". At this stage, I should have seen the "red flag" and realize that something is unusually wrong here. But I decided that if I would install failsafe first (which is supposed to contain some basic launching code), the main part has a chance to start.
I ran failsafe, it upgraded successfully. But when I ran reinstall again, I got the same error message. I thought OK, I'll look at it later, but now I have to drive somewhere. I started the engine and set out. Everything worked fine.
When I arrived to my destination, I left the car and came back in half an hour. When I started the engine again, the screen was black. Nothing worked, except for the last radio channel that was tuned in (luckily it was the classical music one), and the volume and mute controls. The unit obviously didn't boot, it was bricked (there was no way to do anything with standard controls).

What was next
With some effort, I took the unit out (the CMU and the screen); there are videos and pictures in the web how to do it (e.g. here); the service manual is helpful too. At first, I made an attempt, as it was written here, to connect to the TTL console via the known pins of the connector; then I even opened the unit's case and soldered wires right to the PCB contacts. There were no signs of life; now I understand there could not be any.
Only two ways were left: either buy a new CMU (I found some on eBay), or get the old firmware back. From these two pages, I realized that what is to be restored is the SPI NOR flash, a 8-megabyte chip. When I opened the case, I looked at its type, it was Spansion S25FL064A. After some search in the Web, I've found that it's quite possible to reflash it with minimal "investments". I started two things in parallel: on eBay, I ordered a used CMU and a programmer device. The CMU arrived first, but it was not working; I got a refund and sent it back.

What to do
Here is what you need to unbrick your CMU:
  • know that it's quite possible and not that hard;
  • at every stage, know exactly what you're doing and understand possible risks (if your unit is bricked, you have probably nothing to lose except for the chance to repair it);
  • buy a USB programmer based on the CH341A chip ($3.5 on eBay, $10 on Amazon);
  • find a way to unsolder a SOIC-16 chip from the PCB and then solder it back. You may need a soldering iron with special soldering tips; I was lucky to have a friend, an electronic engineer, with necessary equipment and skills. Be careful with (un)soldering, PCB tracks may be damaged by overheating!);
  • be able to analyze the firmware structure, understand what was wrong and how to fix it at the level of binary editing.
    Note: you probably don't have to unsolder the chip. There exist programmer test clips for such chip packages. I ordered one on eBay but it came too late, I managed without it. I don't know if the programmer would work with the chip staying on the PCB. With this clip, you'll need some soldering too (wires etc.), but without the risk to damage the chip or PCB tracks. The clip looks like this:

    If you succeeded to reflash the chip in place (without unsoldering) using the clips, please let me know.

    When I received the programmer, I installed the software which is easy to find in the web; there are YouTube videos where people install it. The programmer is suitable for several kinds of chips; this is how it looked when assembled with my chip, soldered on the special panel (which is enclosed with the device):



    There is a jumper there, initially connecting pins 1 and 2; you don't need to change it, this position fits the driver installed with the CH341PAR.EXE installer (there is another one, CH341SER, which you won't need). Besides the chip, we soldered two rows ot contacts to the panel, they were also included in the package. You can see how they should be soldered on the picture. In fact, this panel is an adapter between the 16-pin chip and the 8-pin half of the socket. (The other half of the socket is for other chip types, we're not interested in it.)

    Healing the binary contents
    I unzipped several failsafe.up packages from different firmware versions (the older one, the newer one, and also several yet older and yet newer versions), they are zip files with the same known password (you can find it in the web). Inside each one, besides root files, there are three directories: bootstrap, fail-safe and ibc2. Each directory contains a number of .gz files, I unpacked them too. They are regular gzip packages.

    When the programmer (with my chip in it) was ready, the first thing I did was of course reading the 8-megabyte contents and saving it in a file. Thanks to this page (really thanks!!) I knew what I had to do with it.

    In the bootstrap directory of each package, there are three files, e0000000001.dat, e0000000002.dat and execute.ini. The contents of the .ini file implies that the actual name of e0000000001.dat is update-bootstrap.sh (that is, a shell script starting the upgrade), and e0000000002.dat is actually ibc-cmu-bootstrap.bin, which is the contents of the bootstrap partition itself. The ibc2 directory contained the binary.ini file and two parts of the ibc2 partition. In the fail-safe directory, I found another binary.ini and four parts of a bigger binary file sliced in 2M pieces.

    I compared partitions of the chip with the files I unpacked. The contents of the bootstrap partition was exactly equal to the file e0000000002.dat from the bootstrap directory of the new firmware. Interestingly, up to the version 56.00.513B, the bootstrap code was the same in all versions; it changed in 59.00.443C, and all subsequent packages have the same bootstrap code too. This means, the trap was just in this upgrade. Further, the contents of the ibc1 partition on the chip was identical to the ibc2 file from the old firmware, and ibc2 partition was identical to the new ibc2 file. That is quite logical: ibc1 loads the main system which was not upgraded, but ibc2 was upgraded together with the failsafe code. And finally, the fail-safe partition was an exact copy of the sliced binary file from the unpacked fail-safe directory, about 7.5M.

    It was clear that all I have to do is replace all new parts of the firmware with the old ones, that is, the bootloader, ibc2 and fail-safe. I didn't touch configuration sections; other partitions were either absent or contained some data including version number in the text form, I changed the version to the old one and dind't touch the rest.

    There was some doubt whether I should change one byte at the address 0x10000 ("boot-select"), from FF (boot the main system from ibc1) to 00 (boot failsafe from ibc2 to start upgrade from the USB drive). I reasoned that all I needed for the system to work was restoring the old bootloader as it was, and there was no reason to start the failsafe part at all. At the same time, I realized that my case is virtually the same that was described on the same page: the new bootloader wouldn't load the old main part of the firmware. Only the treatment was different.

    I flashed the chip (it took two extra times to flash it before I figured out I have to erase it first, otherwise nobody would turn zero bits into ones for me). My friend soldered the chip to its place on PCB, I connected everything and the system booted as if nothing had happened.

    Update Oct 2017: Now I successfully upgraded to EU 59.00.449A (first failsafe, then reinstall, no reboot between them). I think my USB drive was defective when I made the previous attempt, but I didn't try again with that unlucky 59.00.443C.
  • 57 comments or Leave a comment
    Comments
    From: (Anonymous) Date: October 17th, 2017 10:20 am (UTC) (Link)
    U wrote "I didn't touch configuration sections; other partitions were either absent or contained some data including version number in the text form, I changed the version to the old old one and dind't touch the rest."

    Where did u excactly changed the version number? U talk about "some data" :D

    Thank you very much!
    yms From: yms Date: October 22nd, 2017 10:16 pm (UTC) (Link)
    Somewhere in the end of the config section, about offset 0x7E5C30 of the ROM, and probably in some other place wherever I found it (searchable in the editor).
    (no subject) - (Anonymous) - Expand
    (no subject) - (Anonymous) - Expand
    (no subject) - (Anonymous) - Expand
    password - (Anonymous) - Expand
    Re: password - (Anonymous) - Expand
    Re: password - (Anonymous) - Expand
    Re: password - (Anonymous) - Expand
    From: (Anonymous) Date: October 20th, 2017 08:08 am (UTC) (Link)
    How were you able to change the Image of the Chip? Which program did u you use for changing the files?
    yms From: yms Date: October 22nd, 2017 10:22 pm (UTC) (Link)
    I used my own simple command-line program which copies binary file fragments, but it's also possible to use any binary editor, e.g. the one built in the Visual Studio.
    From: (Anonymous) Date: November 4th, 2017 09:10 am (UTC) (Link)
    Hi, would you do this repairing bricked units as a side business? I have the exact same problem you had. Fail safe installed but the other one had failed validation. Now black screen radio hiss only nothing else.
    yms From: yms Date: November 8th, 2017 07:16 pm (UTC) (Link)
    No, no, I just can share my experience, don't want to convert it into business (and have no time), sorry.
    From: (Anonymous) Date: March 7th, 2018 06:48 pm (UTC) (Link)

    password?

    you said "I unzipped several failsafe.up packages from different firmware versions (the older one, the newer one, and also several yet older and yet newer versions), they are zip files with the same known password (you can find it in the web). "I couldnt find it. what is the password?
    yms From: yms Date: December 5th, 2018 08:33 pm (UTC) (Link)

    Re: password?

    didn't see your comment in time, now changed the post settings. The answer is in another thread.
    From: (Anonymous) Date: August 28th, 2018 02:02 pm (UTC) (Link)

    Can you help me to unbrick my car's CMU

    Hi yms !
    My car verrsion 59.00.540ADR and it get stuck on boot logo when install USB Video Player 3.5, i tried to restore all file to original, but no luck!

    I try this solution by reflash an image of SPI chip (version 56.00.513 ADR) and set the failsafe flag, it boot up to failsafe load, but when insert usb stick with 59.00.513 reinstall.up file to usb port, it show validating 56.00.513.... run about 20% (i looked up on serial console) and reboot to failsafe load again and again...
    I don't know why it happend!

    PS: i powered CMU up outside of the car!

    Can you help me to recover My car's CMU...

    Thank and best regards!
    From: (Anonymous) Date: September 27th, 2018 02:04 am (UTC) (Link)
    Could you show me how to flash the chip, I load the e0000000002.dat to the IC but cannot boot up the cmu.I just hear the radio only.
    yms From: yms Date: December 5th, 2018 07:35 pm (UTC) (Link)
    didn't see this comment in time, the password is below in one of comments.
    From: (Anonymous) Date: October 18th, 2018 08:59 pm (UTC) (Link)

    chip dump

    Thanks for sharing this information, this is great. Unfortunally I could not recover my unit until now. I have the problem that I had a software version from what I cannot find the original files (V51) I tried to use the V56 files, but without succes. Can on you share your complete file with me? than I can write that onto the chip, should work dont you think?
    From: (Anonymous) Date: October 18th, 2018 09:10 pm (UTC) (Link)

    Re: chip dump

    after reading my own post I realized that this of cause is not the case. I will still have the wrong software in the system, so I need to find the files of the V51. Anyone an idea where to get them?
    Re: chip dump - (Anonymous) - Expand
    Re: chip dump - (Anonymous) - Expand
    Viên Tịnh From: Viên Tịnh Date: November 27th, 2018 03:51 am (UTC) (Link)
    My cmu version was 51.00.351A and i tried to update to version 59.00.449A
    after installed failsafe I accidently do reset via system configure and now my cmu totally bricked
    (not really is my mistake but a tutorial told me to reset after every install file that is a huge mistake to trust that tutorial)
    im tried to flash directly to the chip with some tool but can not found the original 51.00.351A fail safe file.
    then i have to try the version 55 EU one in the fist try was none success but it was because of the cabble and the clip connected with the chip was fault.
    I try again with version 31 and still failed did not know the problem was the cable conneting.
    I did 3nd tries this morning and successed restored the healed binary to the chip.
    Thank you so much for informations. thats every thing i need to unbrick my cmu.
    really appreciate that.

    soic16 clip:
    https://i.imgur.com/n35Xyc6.jpg
    spi NOR flash ic manufacture was Macronix Mx25L6445E
    https://i.imgur.com/s7YHvQe.jpg
    https://i.imgur.com/drxIQ3o.jpg
    firmware before flashing
    https://i.imgur.com/vCthGb6.jpg

    Edited at 2018-11-27 04:05 am (UTC)
    yms From: yms Date: December 5th, 2018 08:32 pm (UTC) (Link)
    Thank you for info!
    (no subject) - (Anonymous) - Expand
    (no subject) - (Anonymous) - Expand
    From: (Anonymous) Date: December 10th, 2018 05:47 pm (UTC) (Link)

    how unzip and zip

    Hello,

    how can i unzip and zip the firmware.
    what program do u use?

    thanks
    yms From: yms Date: December 11th, 2018 02:06 pm (UTC) (Link)

    Re: how unzip and zip

    To unpack ZIP archives with .up extension, you can use any program like WinZip or WinRAR.
    To create the firmware image, you don't need to "zip" it, you need a binary editor and copy/paste chunks of bytes in it.

    Edited at 2019-03-16 08:16 am (UTC)
    From: (Anonymous) Date: January 18th, 2019 02:50 pm (UTC) (Link)
    If you succeeded to reflash the chip in place (without unsoldering) using the clips, please let me know

    I did it, works perfect

    many thanks
    From: (Anonymous) Date: January 20th, 2019 07:19 pm (UTC) (Link)

    In place reflash

    I've purchased a CH341A and a 16 pin clip. Anything special or different from this setup that needed to be done?
    Re: In place reflash - (Anonymous) - Expand
    From: Maco Meza Date: April 13th, 2019 10:36 pm (UTC) (Link)

    What to write back on NAND Flash

    On the link named “this page”, on the last paragraph, author says the following “By deliberately corrupting the NAND-flash, I was able to force the "fail-safe" to start from the very beginning (instead of the partial-resume feature it wants), and that allowed me to "unbrick" the unit. However, for a normal user or mechanic, this bad behavior would require an expensive replacement of the unit.”

    What exactly does it mean? We have to replace the first 4 sections with bootstrap info extracted from a fresh firmware gzip?
    bootstrap 0x000000 0x000000
    boot-select 0x010000 0x010000
    ibc1 0x020000 0x020000
    ibc2 0x040000 0x040000


    Edited at 2019-04-13 10:37 pm (UTC)
    From: (Anonymous) Date: April 14th, 2019 01:04 am (UTC) (Link)

    Re: What to write back on NAND Flash

    It means that by changing the first byte of address 0x10000
    from FF to 00 the guy was able to force a fail safe mode to reload the system from the .up files in the USB. This may or not work.

    The author of this very page approach is different, he replaces the bad sectors of the loaded firmware in the flash chip with the same sectors from the .up failsafe version and booting normal like nothing happens.

    From: (Anonymous) Date: April 20th, 2019 08:56 am (UTC) (Link)

    Pass unzip failsafe.up

    Can you help me Pass to unzip ?
    yms From: yms Date: April 21st, 2019 08:00 am (UTC) (Link)

    Re: Pass unzip failsafe.up

    the answer is in one of the threads above:
    5X/9vAVhovyU2ygK
    From: Maco Meza Date: May 4th, 2019 06:08 am (UTC) (Link)

    CMU working again

    Hi guys,
    I've finally restored my CMU, thank God!
    I bought an used radio on ebay, a programmer CH341A and I am using CH341AFree.exe.
    Then I read the bin from that NAND Flash chip, save it to my storage as rescue.bin.
    Then I erased my damaged chip, then verified it was blank, then open rescue.bin from working CMU and write it to damaged CMU NAND Flash, and it is working again. Then I updated firmware to latest. In a couple days, I will complete Carplay retrofit upgrade. If anybody wants my rescue.bin for North America, I will be glad to help.
    From: (Anonymous) Date: May 8th, 2019 06:25 pm (UTC) (Link)

    Re: CMU working again

    Hello, I would love to grab a copy of your rescue.bin much appreciated.
    Also is it as simple as flashing the rescue.bin onto my bricked cmu to make it boot up again? Thanks!
    Re: CMU working again - (Anonymous) - Expand
    From: (Anonymous) Date: May 24th, 2019 10:57 am (UTC) (Link)
    Is it possible to update only the failsafe in case the bootstrap is the same and won't be updated when I reinstall 59.00.502 on the same firmware. that's because my failsafe is corrupted and displaying "failsafe version not available" in the "About" screen.
    The main OS is running smoothly and as expected.
    The problem rose when I tried to reinstall 59.00.502 with tweaks installed and without doing a full restore of the system; the failsafe installed to about 80% and then stopped with the message "Software update will not be available...". When I rebooted my system, the main OS is still working well (same bootstrap since it didn't get updated), but I corrupted my failsafe image.

    yms From: yms Date: June 23rd, 2019 03:02 pm (UTC) (Link)
    If you have the European version, you can take my failsafe dump (56.00.513) and change the byte at offset 0x10000 from FF to 00, which means "boot from the failsafe version". Then, try to burn it to the chip. But make sure you back up your current firmware first, because if you have 59.00.502, it's incompatible with 56.00.513 failsafe, and I didn't actually check if it boots to failsafe when byte 10000 is changed to 00. If it bricks, you can re-burn the backed up dump.
    But, since your CMU is working now, think twice if you really need to do all this :)

    Edited at 2019-06-23 03:07 pm (UTC)
    李弘彰 From: 李弘彰 Date: June 14th, 2019 10:22 am (UTC) (Link)

    update fail

    I have a MZD connect CMU with firmware 59.00.502 JP,when updating to 70.00.100 ADR,I make a mistake by updating reinstall first and failed,always going to 2% and back to update fail screen,is there anyway to restore it? Thanks for help.
    I already bought a ch341a flasher to flash 70.00.100 ADR into the spi flash,but update is still reboot at 2%.How can I save it?
    57 comments or Leave a comment