?

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 launched reinstall, after some time it said, "Failed to validate package certificate". At this stage, I should have noticed the red flag and realize that something is unusually wrong here. But I thought, 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 go 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.
  • 24 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).
    From: (Anonymous) Date: October 23rd, 2017 08:51 pm (UTC) (Link)
    Thank you for your quick answer.

    Now i think i got everything, i found it on two places in the ROM File and changed the bootstrap, ibc2 and fail-safe partition.

    All i have to do now, is to bring it back on the UNIT.

    I really have to say THANK YOU for your explainings. I made every step and i hope that in a few days my car will be fixed =)

    U saved me a lot of money!
    I really have to say THANK YOU again :D

    Greetings!
    yms From: yms Date: October 23rd, 2017 09:27 pm (UTC) (Link)
    I hope you'll put the ROM back and the unit will start successfully.
    It's always pleasant to know it helped somebody!
    From: (Anonymous) Date: October 27th, 2017 10:15 pm (UTC) (Link)
    SUCSESS, the CMU is booting now without any problems. U made a great job to set up the instructions here!
    yms From: yms Date: October 28th, 2017 05:48 am (UTC) (Link)
    Wow, congratulations!! I'm glad as much as I was when I unbricked my own unit :)
    From: (Anonymous) Date: November 18th, 2017 10:53 am (UTC) (Link)
    Now after i few days, i updated to new firmware 59. ... and installed Android Auto, that is really great!
    yms From: yms Date: November 18th, 2017 10:06 pm (UTC) (Link)
    Congrats :)
    I didn't succeed with Android Auto, maybe I'll retry later.
    From: (Anonymous) Date: March 8th, 2018 06:23 pm (UTC) (Link)

    password

    what is the zip password to extract?
    yms From: yms Date: March 8th, 2018 07:29 pm (UTC) (Link)

    Re: password

    See here the answer #10.


    Edited at 2018-03-08 07:30 pm (UTC)
    From: (Anonymous) Date: March 9th, 2018 07:35 pm (UTC) (Link)

    Re: password

    You are really Great! thx so much.
    From: (Anonymous) Date: March 23rd, 2018 08:13 am (UTC) (Link)

    Re: password

    you said:
    There was some doubt whether I should change the byte at 0x10000 address ("boot-select") from FF (boot the main system from ibc1) to 00 (boot failsafe from ibc2 to start upgrade from the USB drive).

    did you mean change from 0x10000 till 0x1ffff all as 00 ?
    I checked bootstrap, ıbc2 and failsafe but didn't work.
    and
    you said I flashed it. what is the "flash" how did you do that?

    I'm doing something wrong. maybe you can help me to find it.

    yms From: yms Date: March 24th, 2018 05:56 am (UTC) (Link)

    Re: password

    I mean "ONE byte at 0x10000". The rest of the bytes should remain FF. But I didn't try actually to set it to 00.
    By "I flashed the chip" I mean "I filled the chip memory using the programmer device, clicking the Write (or Program) button in the software".
    From: (Anonymous) Date: March 24th, 2018 12:17 pm (UTC) (Link)

    Re: password

    ı did it. :) really thx. my system working now. you are right it dont necessary to change ff to 00 at 0x10000. just ı change bootstrap partion with failsafe bootstrap e0000000002.dat. I check that failsafe and ıbc2 same with firmware and didnt change anything.

    I understand that e0000000001.dat for update mode e0000000002.dat for normal mode at bootstrap partion.

    anyway. I saved my system and so my Money :) thank you again for advices.
    yms From: yms Date: March 24th, 2018 04:32 pm (UTC) (Link)

    Re: password

    you're welcome :)

    Edited at 2018-04-16 08:31 pm (UTC)
    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: 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.
    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?
    From: (Anonymous) Date: October 19th, 2018 04:35 pm (UTC) (Link)

    Re: chip dump

    Just to let you know, I did managed to get my unit working again, so thanks again for your information. I created the file again and now I succeeded with the use of the v55 files.
    For information, I tried also to only change the boot select bit, but this did not help to solve the issue, bringing back the old files did the job.
    yms From: yms Date: October 22nd, 2018 08:45 pm (UTC) (Link)

    Re: chip dump

    Great!
    24 comments or Leave a comment