Black Screen MZD

Thanks. Good to know, as its the 1st time I use this tool. But even if I erase successfully (and did the blank check successfully), I can neither write directly nor can I open&write the "bin-file" with the previously patched value "00". I always get the same write error shown in the screenshot of my previous post. Any other idea?

I tried:
a) read -> erase -> blank -> write (always with value 00 at line 10000) = unsuccessful
b) read -> erase -> write = unsuccessful
c) read -> erase -> open (bin file with value 00) -> write = unsuccessful
d) read -> erase -> blank -> read (all values are still FF) -> write = unsuccessful
e) verify (status: chip main memory are blank) -> open (bin file with value 00) -> write = unsuccessful
f) open (bin file with original value FF) -> write = 100% and then no error message, so I guess it was successful, even if thats not what I want to achieve - so basically the write function might work.

The connection schema/pattern shown in post#16 is the view from the top to the CH341 programmer, right? So the connections should look like this (I added red/blue lines just as example).

My chip is the same as shown in this thread:

...and I installed the 64bit drivers, as at my Win10 64bit the linked 32bit drivers could not be installed. Source: karadev.net/basto/CH341A-programmer-software-1.29/ -> ZIP File PAR 2.2

Thanks again. I erased the chip, opened your/macomeza`s linked file above, wrote & verified it to the chip, but the cmu is still dead. No sign of life, when connected. Display is still black and serial access does not show any text flying by - just a non moving green square. Please find attached my original *.bin-file, which I read/saved/backupped before doing changes: Downloadlink
Correct, as I do not know the origin of the brick/how it got bricked, it also could be e.g. a hardware issue or something else. I already checked the wiring, but my usually installed cx-5 CMU has the same wiring as this bricked mx-5/miata CMU.

I use nearly the same test clip as you:

PS: And I emailed with Vien Tinh, but he knew exactly how he bricked his cmu back then and he manually fixed it by copying the hex values of the failsafe firmware files to the correct offset section at the cmu chip and this worked for him. I also tried this, but unfortunately without success.

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.

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.

Correct, I have the following CMUs to play around with at my bench setup:

1. dead CMU, not booting, of an MX-5/Miata, SPI NOR chip erased without a backup (my first inglorious try with the chip clip).
2. dead CMU, not booting, of a M3, 56.00.513B EU reinstall was at the SPI NOR chip originally.
3. working CMU of a CX-5 (currently running 70.00.352 EU)

For 1. and 2. I was told by the previous owners, that the death came slowly. The MZD sometimes booted and sometimes not. They both did not install any tweaks or performed FW updates by themselves.

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.