[Tristan-cx5]

May I ask what the solution looked like? With this info future similar problems might get solved as well.

 

[Dusanr]

I have used CH341A programmer and uploaded new rom file supplied by Alama12 and then it was possible to finish installation of the new firmware. Working with CH341A programmer is not very easy, mostly because you have to connect 8 pins from 16 pin clip to 8 pins on the programmer, it was the first challenge, but you can find here on forum what pins from 16 pin clip connect to 8 pin connector and second one was to find correct fit of the clip on the chip, it took several tries. This is the best tutorial video

. In my case, it wasn't enough to replace that one line with nulls, it didn't help, I had to upload new rom file. If you need some more info, just reply to this post.

 

[KKC]

I would put 70.00.100 to the usb stick and check the hash/checksum before inserting it to the car's usb hub.
If this does not work, you could try a bin file posted here in the thread and try to install the according firmware file(s). You could use the EU version and install EU firmware version. Afterwards you can install any other region version - e.g. ADR.

Hello Tristan-cx5,

What is the firmware that I need right after I modified my CMU with your rom-513B.bin?

Do I need the EU 513B_reinstall.up? Can you share the drive with firmware for us to download?

Currently, I can only download the EU version firmware:
cmu150_EU_59.00.545A_failsafe.up
cmu150_EU_59.00.545A_reinstall.up
cmu150_EU_70.00.100A_failsafe.up
cmu150_EU_70.00.100A_reinstall.up
cmu150_EU_70.00.367A_update.up

North America Firmware version:
cmu150_NA_70.00.100A_failsafe.up
cmu150_NA_70.00.100A_reinstall.up
cmu150_NA_70.00.367A_update.up

ADR firmware:
cmu150_ADR_70.00.100A_failsafe.up
cmu150_ADR_70.00.100A_reinstall.up
cmu150_ADR_70.00.367A_update.up

 

[Tristan-cx5]

It is not "my" file - see post #84. @craz posted it.
Posting links to servers with firmware files is not recommendable, as Mazda will let the servers delete really quick - like often in the past.

Edit: I guess that you would need 56.00.513... I can not remember properly, as 3 years passed since then... all I know I wrote in this thread here.

 

[Mistadave]

.

 

[Mistadave]

I would put 70.00.100 to the usb stick and check the hash/checksum before inserting it to the car's usb hub.
If this does not work, you could try a bin file posted here in the thread and try to install the according firmware file(s). You could use the EU version and install EU firmware version. Afterwards you can install any other region version - e.g. ADR.

Thanks Tristan,
I'm going to try 2nd step but I not have 56.00.513 EU firmware.
Can you help me.

Regards,
Dave

 

[ChrisMZ]

Update: my CMU is working again! It seems my .bin file was corrupted or wrong. First time when I started the upgrade I had failsafe and reinstallation files with wrong checksums and maybe this wrong failsafe stored in Flash Memory. Later when I had the correct FW, the update failed again. Also the Testclip caused a lot of headache due to the wrong contacts. I measured 4-5 times the wires with multimeter to get the good contact, everything looked perfect but reprogramming the Flash Memory failed (I have 2 sets of Testclips and adapters). Finally I soldered the wires directly to the chip, corrected .bin file uploaded (Trafmaster sent me a perfect rescue .bin, thank you!) to Flash Memory and success!

Is there any chance i could get ahold of the rescue .bin? I'm in a 2%-3% boot loop on fail safe trying to get from 59.00.504 4A N to 70.00.100A

 

[Alma12]

Is there any chance i could get ahold of the rescue .bin? I'm in a 2%-3% boot loop on fail safe trying to get from 59.00.504 4A N to 70.00.100A

I sent you a PM.

 

[toptyurin]

Hi everybody. It seems that my NOR flash burned. I have bought new one but I need dump of this chip. Who can share?

 

[Tristan-cx5]

Have you read this thread? Some dumps were shared already. Maybe these help you?

 

[Mistadave]

I sent you a PM.

Hi Alma,

Can u share with me too..
Really need ur help..

Dave

 

[toptyurin]

Have you read this thread? Some dumps were shared already. Maybe these help you?

Sorry, checked last 4 pages but it was on page 3. Will try this, thanks a lot. Hope it will help me.

 

[Luchini]

Hello, could you guide me on what I should look for to be able to buy the ch431a and soic16 sop16 usb to ensure the purchase and without making mistakes... please, since my cmu is apparently blocked, I appreciate your help. (I'm using google translate).

 

[chechomro]

thanks so much, i unbrick my cmu with ch431a but it only work for me the "rom-513b.bin" posted here in the forum, and i just looking for the last version 74.00.324A ADR

 

[tanjunzhi4154502]

Hello everyone. I sucessfully installed tweaks but I have 2 problems.

1) When I plug my phone, I see notifications on my phone says "android auto connected" again and again and mazda's screen goes to black. I tried with another phone and bought new high quality cable but the result hasn't changed. After trying a couple of things on android auto app on the phone (forget all cars, connecting wireless etc), my phone says "connecting to android auto" but nothing happens.

2) After downgrade & upgrade I saw all my previous bluetooth connection list and I cannot remove them.

I would be happy if anyone could help me to fix these problems.

Thank you

Hello, how did you achieve installation and debugging? I have been unable to install it

 

[STANe]

Hello! I had my headunit bricked when trying to install 70.00.100 - it stuck at 2%. Using the clip didn't work for me, so I lost the original SPI NOR Flash. However, I managed to solder out the chip and flashed the dumps from this thread. The last one was failsafe 70.00.100. The headunit starts, asks for usb source, validates the firmware however doesn't start installation and goes into reboot. Of course, I tried different versions and usb cards. Any chance to solve this issue?

 

[Luchini]

Hello! I had my headunit bricked when trying to install 70.00.100 - it stuck at 2%. Using the clip didn't work for me, so I lost the original SPI NOR Flash. However, I managed to solder out the chip and flashed the dumps from this thread. The last one was failsafe 70.00.100. The headunit starts, asks for usb source, validates the firmware however doesn't start installation and goes into reboot. Of course, I tried different versions and usb cards. Any chance to solve this issue?

I am in the same situation as you, I have the loop that reaches 2-3% of installation, and I tried many things without finding a solution. Since I have not found a solution, I decided to buy the new cmu.

 

[craz]

The following is from an engineer who tore down and analyzed the infotainment system back in 2016, read in special at the end in bold. He doesn't say how to corrupt NAND flash, ibc1??
Please If someone reads this post and is good at ARM and Linux and has an idea how to do it, please post in this thread. It'll help lots of people with a continuous reboot searching for a point it left off to continue the installation.

"It uses an 8MByte SPI NOR flash for booting. The lion's share of that memory goes to a Linux-based "failsafe" image to upgrade firmware. However, despite the name, it is anything BUT failsafe in operation.

The memory is segmented as follows:

official partition name	offset prior to v31	offset after v31
bootstrap	0x000000	0x000000
boot-select	0x010000	0x010000
ibc1	0x020000	0x020000
ibc2	0x040000	0x040000
nv-config	0x060000	0x060000
config	0x070000	0x070000
jci-boot-diag	n/a	0x0D0000
fail-safe	0x0E0000	0x0E0000
update	0x7E0000	0x7E0000

The bootstrap image corresponds to the Boot Devices Program image documented by Freescale for the i.MX6. Based on the state of the boot-select partition, it either executes code from ibc1 (normal operation) or ibc2 (upgrade operation).

Execution from the ibc1 goes to the NAND-flash image (~5GBytes of storage) main application. Execution from the ibc2 goes to the 7MB "fail-safe" image.

The "fail-safe" image is what drives the LCD display to provide the progress bar during the lengthy upgrade process. It reads an upgrade image from a USB drive and reprograms the NAND-flash as well as the firmware of on-board peripherals.

For the user, upgrading the firmware consists of two portions: the "failsafe" (bootstrap, ibc2, and fail-safe) and the application (ibc1, NAND-flash, and peripheral firmware).

JCI's reasoning was clearly rooted in the (misguided) belief that this made it failsafe, since the unit will only boot to ibc2 + fail-safe until the firmware is completely updated. However, as always, the devil is in the details.

The most vulnerable portion of the firmware update is any writes to the bootstrap. If the user's "failsafe" image contains a different bootstrap image, the code gleefully rewrites it. A power failure at this point effectively "bricks" the unit with no hope of recovery.

I take issue with such a design. In my opinion, such bootstrap code should NEVER be re-written in the field. It is such a small enough amount of code (under 3 kBytes) that it should be heavily tested and audited in development, programmed in the factory (preferably in a write-protected portion of memory), and never touched again. However, this is not what JCI has done.

Another questionable design is the "fail-safe". As an experiment, I deliberately disrupted power during the fail-safe execution.

The result was a "bricked" unit. It endlessly rebooted (briefly flashing the backlight of the display each time). I've provided the exact console output that was endlessly repeated.

The failure mode was as follows: rather than adopt the safest practice of starting the upgrade process from the very beginning at every boot of the boot-strap code, it tries to detect existing NAND-flash partitions and resume from the point it left off. No doubt, they thought their super-fancy NAND-flash routines (advertised as "risk-free mobile data") would protect them. However, that hubris was to assume the entire file system AND the hardware was going to be in the exact same state as before the disruption. As a result, the "fail-safe" code just FAILS... and this is exactly what it should NOT do.

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. "

 

[fuckencio]

Hello friends, I tell you that I was able to connect with the programmer to the radio and load the backup bin that is in Google, when I turn on the radio it asks me to insert the pendrive, which I insert, detects the FW 70.00.100 and restarts the radio... how do I solve that or he literally already died.

Do you have another recovery bin to try?

 

[Tristan-cx5]

In this thread should be more than one bin file.