@Tristan-cx5 could you expalin how did you do a backup? Its only 2 steps job?
1- read
2- Save file as. xxx.bin?
Or i am missing something here?
1- read
2- Save file as. xxx.bin?
Or i am missing something here?
Black Screen MZD
81 - 94 of 94 Posts
Joined
·
1,649 Posts
Sorry for the delay, funny, this is the 3rd or 4th failed EU version 56.00.513B I've seen, please try this file I'm attaching it should work, rename to *.bin. Difference with original are some stored settings in NV and also version name somehow it was renamed to "reinstall.up" maybe the user run that first instead of failsafe.up.
Joined
·
1,649 Posts
No worries - no one is in a hurry. Thanks for checking and sending me the file. I erased the chip (+checked via blank-button), opened your file, wrote it to the chip, veryfied it, hit exit, disconnected the clip, put the cmu board in the housing and connected the cmu to my bench setup (verified working with cx-5 cmu`s so far, wiring is not different to mx5 or m3 CMUs). But nothing happened, when I powered it. Just a black screen. Did the procedure incl. writing to the chip again, same result. Then I changed in your file at line 10000 the first values from FF to 00, but still nothing to see at the display. Then I connected a cx5-CMU and the display worked. Might it be, that the CX-5 display (build in dashboard, instead of on top of dashboard like at M3/MX-5/Miata) is not working with other CMUs? Or do I have to run the CMU in the car for some reason? My bench has a CX-5 display, old usb hub and a commander knob.
Your assumption, that the user of this CMU did something wrong might be partially right and wrong: The user does not know how to perform firmware updates and had the car at the dealership (Sept. 2020). They told him, that the latest firmware has been installed by them (so if something went wrong while installation, it was the fault of the dealership). And after 1-2 weeks after the said-to-be-update-by-dealership (not checked by user/customer) the display went black sometimes and then completely. Then a new CMU was sold/installed.
Or its not the SPI NOR chip, which lead to the non working CMU, but some other chip/condensator/cold soldering connection. But how to check all the connections at the CMU board? I have a multimeter and know how to use it, but these are so many connections.
Your assumption, that the user of this CMU did something wrong might be partially right and wrong: The user does not know how to perform firmware updates and had the car at the dealership (Sept. 2020). They told him, that the latest firmware has been installed by them (so if something went wrong while installation, it was the fault of the dealership). And after 1-2 weeks after the said-to-be-update-by-dealership (not checked by user/customer) the display went black sometimes and then completely. Then a new CMU was sold/installed.
Or its not the SPI NOR chip, which lead to the non working CMU, but some other chip/condensator/cold soldering connection. But how to check all the connections at the CMU board? I have a multimeter and know how to use it, but these are so many connections.
@craz @Tristan-cx5 Maybe some of you guys will be able to help me. I've found what version was inside of dead CMU - it was 33.00.100A EU N. I've tried this method and screen worked for a moment to let me try install firmware again. I've recorded a video. It last around 2 mins and please watch it till the end. I've started on purpose with 59.00.502 EU N and 70.00.100A and 3rd pendrive had the correct firmware 33.00.100A. Then something strange happned and you can see that on the video - for 1 or 2 sec I've seen installation progress bar and then out of the blue information that installation was successfull which is not possible to happen that quickly. When I restarted CMU there is only Mazda logo and nothing more.
Link to youtube video ->
Performed method:
1. I've done it with 6x test clips and rapberry pi and I've sent all command described here
2 I've used SOC16 Clip and CH341A programmer and after that I've changed FF to 00 in address 10000.
Questions:
1. Any idea how to deal with this impossibly fast installtion which leads to constant Mazda logo view?
2. After 1st and 2nd method I've received the same effect as you can see on the video. So my question is if the 1st and 2nd method are the same thing just different approach and required tools?
![279987]()
Link to youtube video ->
Performed method:
1. I've done it with 6x test clips and rapberry pi and I've sent all command described here
2 I've used SOC16 Clip and CH341A programmer and after that I've changed FF to 00 in address 10000.
Questions:
1. Any idea how to deal with this impossibly fast installtion which leads to constant Mazda logo view?
2. After 1st and 2nd method I've received the same effect as you can see on the video. So my question is if the 1st and 2nd method are the same thing just different approach and required tools?
Yes, you are right, 1st and 2nd menthod are the same... but 2nd menthod is more quickly than 1st do...
You get quick install firmware to that screen because you using the backup .bin of the original version firmware preinstall by factory, you may be can try use other CMU working with firmware install by user and then do backup this CMU to .bin file, after that use this .bin file to flash to bricked CMU and try to reinstall new firmware....
Joined
·
1,649 Posts
In post #79 you'll find the SPI NOR chip backup of my working 70.00.352 EU and in post #84 a 56.00.513 EU of craz which should work (could not verify it so far due to probably other reason of my dead CMU than a bricked SPI NOR chip).
Edit1: And here you`ll find the original SPI NOR Chip content of working 70.00.100 EU & 59.00.502 EU (rename *.pdf to *.bin). Just in case someone somewhen needs it.
Edit2: I just did some tests with a working CMU.
a) 70.00.100 installed (reinstall + failsafe), value FF changed to 00 at line 0x010000. Request for reinstall was shown at the MZD display. At the inserted usb stick were both files of 59.00.502 and 70.00.100. The system chose the lower one to install (59.00.502). Afterwards the firmware was shown in the MZD 59.00.502 and the failsafe was still 70.00.100, but it worked. Then I manually installed the failsafe of 59.00.502 to be both 59.00.502.
b) 59.00.502 (failsafe+reinstall) was installed, I reased the SPI NOR chip and wrote the 56.00.513 file from craz to it. It worked.
c) With this working version from b) I tried to install FW 56.00.513, but it was not shown at the usb stick (as I expected it, as from 59.00.502 or + you can ot downgrade any lower than 59.00.502, but I wanted to try it.
d) With this working version from b) I changed the SPI NOR (56.00.513) value to 00 in 0x010000. Then the CMU requested a firmware file. It was not possible to update to 70.00.352, 70.00.100 and not to 56.00.513. For all three files the validation process started, but was canceled and I was requested to install the correct firmware. Instead of doing so, I erased the SPI NOR again and copied the fitting 59.00.502 backup back to the chip as this was faster than installing a new firmware. So it is also not possible to install FW 56 that way, if you were on FW 59.
... these are just my testing results of today. Perhaps they are interesting for someone.
Edit1: And here you`ll find the original SPI NOR Chip content of working 70.00.100 EU & 59.00.502 EU (rename *.pdf to *.bin). Just in case someone somewhen needs it.
Edit2: I just did some tests with a working CMU.
a) 70.00.100 installed (reinstall + failsafe), value FF changed to 00 at line 0x010000. Request for reinstall was shown at the MZD display. At the inserted usb stick were both files of 59.00.502 and 70.00.100. The system chose the lower one to install (59.00.502). Afterwards the firmware was shown in the MZD 59.00.502 and the failsafe was still 70.00.100, but it worked. Then I manually installed the failsafe of 59.00.502 to be both 59.00.502.
b) 59.00.502 (failsafe+reinstall) was installed, I reased the SPI NOR chip and wrote the 56.00.513 file from craz to it. It worked.
c) With this working version from b) I tried to install FW 56.00.513, but it was not shown at the usb stick (as I expected it, as from 59.00.502 or + you can ot downgrade any lower than 59.00.502, but I wanted to try it.
d) With this working version from b) I changed the SPI NOR (56.00.513) value to 00 in 0x010000. Then the CMU requested a firmware file. It was not possible to update to 70.00.352, 70.00.100 and not to 56.00.513. For all three files the validation process started, but was canceled and I was requested to install the correct firmware. Instead of doing so, I erased the SPI NOR again and copied the fitting 59.00.502 backup back to the chip as this was faster than installing a new firmware. So it is also not possible to install FW 56 that way, if you were on FW 59.
... these are just my testing results of today. Perhaps they are interesting for someone.
Good job Tristan, do you have 2 dead CMU's now?
In version 56.00.513 you posted it was clear the system wrote reinstall.up and it was looking in USB for /mnt/sda1/cmu150_EU_56.00.513B_reinstall (1).up at location ( 0x07e000) instead of /mnt/sda/cmu150_EU_56.00.513B_failsafe.up
Following the instructions here Unbrick I checked all boostrap, ibc2 and failsafe sectors and they were identical with v56.00.513 except for those changes .
@dammy89 follow the same site and using a hex editor try restore those sectors in version V31 but read CHIP and save it first and don't forget to restore location 0x10000
In version 56.00.513 you posted it was clear the system wrote reinstall.up and it was looking in USB for /mnt/sda1/cmu150_EU_56.00.513B_reinstall (1).up at location ( 0x07e000) instead of /mnt/sda/cmu150_EU_56.00.513B_failsafe.up
Following the instructions here Unbrick I checked all boostrap, ibc2 and failsafe sectors and they were identical with v56.00.513 except for those changes .
@dammy89 follow the same site and using a hex editor try restore those sectors in version V31 but read CHIP and save it first and don't forget to restore location 0x10000
Joined
·
1,649 Posts
Correct, I have the following CMUs to play around with at my bench setup:
Thanks a lot for checking the 56.00.513 backup file (of 2. dead CMU). So, as the CMU is not booting with the original *.bin file and not with your patched one for the failsafe file, I guess we run out of options for fixing the CMU with some SPI NOR chip edits?! And as the death came slowly and the CMU booted sometimes and sometimes not - and only after that behaviour it was completely dead, I assume, that it is a bad/cold soldering, some burnt chip or some power or ground connection, which went bad over time. But I do not know where to start to measure with the multimeter, as there are so many connections on the platine.
It is strange, that the potentially wrong performed update to 56.00.513 has an uncommon file name at location (0x07e000): "cmu150_EU_56.00.513B_reinstall (1).up" - this indicates, that the dealer downloaded that file at least to times and chose to copy the file with the " (1)" addition to the usb and performed the update with that file first (which was wrong). I am glad, that I can update myself and do it correctly and not have to trust a dealer like that.
- dead CMU, not booting, of an MX-5/Miata, SPI NOR chip erased without a backup (my first inglorious try with the chip clip).
- dead CMU, not booting, of a M3, 56.00.513B EU reinstall was at the SPI NOR chip originally.
- working CMU of a CX-5 (currently running 70.00.352 EU)
Thanks a lot for checking the 56.00.513 backup file (of 2. dead CMU). So, as the CMU is not booting with the original *.bin file and not with your patched one for the failsafe file, I guess we run out of options for fixing the CMU with some SPI NOR chip edits?! And as the death came slowly and the CMU booted sometimes and sometimes not - and only after that behaviour it was completely dead, I assume, that it is a bad/cold soldering, some burnt chip or some power or ground connection, which went bad over time. But I do not know where to start to measure with the multimeter, as there are so many connections on the platine.
It is strange, that the potentially wrong performed update to 56.00.513 has an uncommon file name at location (0x07e000): "cmu150_EU_56.00.513B_reinstall (1).up" - this indicates, that the dealer downloaded that file at least to times and chose to copy the file with the " (1)" addition to the usb and performed the update with that file first (which was wrong). I am glad, that I can update myself and do it correctly and not have to trust a dealer like that.
Joined
·
1,649 Posts
Please do not do double posts... as I already answered in the other thread, where you posted the same question: I do not think that a wireless keyboard will help you, if it is connectable. Try this first:
Joined
·
1,649 Posts
The dealership can not repair the CMU. They will offer you to buy a new one (1000 € at least). If you are still in warranty time, try to get one for free, but I doubt that you will. The other option to fix the CMU is the link to raoulh`s manual how to fix a bricked CMU with extra hardware (in the thread: Black Screen MZD). No other way is known so far.
81 - 94 of 94 Posts
Join the discussion
Join now to ask and comment!