2004 to 2020 Mazda 3 Forum and Mazdaspeed 3 Forums banner
Cancel
Create thread New Garage Forums

Black Screen MZD

Tags
black mzd screen
Jump to Latest
192K views 318 replies 112 participants last post by  ragnar_Xrz  
#69 ·
I found 3 different options:
  1. SSH connection via usb-ethernet-adapter: Use e.g. WinSCP to browse to /jci/version.ini and copy&open it - in there are the firmware version info located. More details see this post: Stuck in an installation loop from V.59 to V.70
  2. Serial connection: Show firmware version in Putty - see details in this post: Stuck in an installation loop from V.59 to V.70
  3. Serial connection: Copy /jci/version.ini (with firmware version in it) to a FAT32 formatted usb stick to later read the file content - see details in this post: Stuck in an installation loop from V.59 to V.70
I would recommend option 3.
 
#70 · (Edited)
Perhaps someone (e.g. @raoulh ) can help me?
I have a dead spare CMU. I got it as defective. I do not know why its not working. It does not start at all. When powered, the display stays black. And also via serial connection there is no sign of life. I hope/thought, that I could revive it with flashing the SPI NOR chip. I got all the parts Viên Tịnh mentioned and hooked the chip up correctly (checked 3 times), as I can successfully read the chip & make a backup *.bin file. But when I try to write the value 00 as recommended by raoulh, then an error shows up: "Write operations timeout failed" (see screenshot). I use the WRITE button in the top row. Please let me know what I can try to successfully write. Thanks.

Error:
 
#72 · (Edited)
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
 
#73 ·
After 2 more reconnects and the re-installation of drivers and using CH341A Programmer Version 1.34 (before 1.29) I could finally write value 00 to line 10000. But still the display stays black after connecting the cmu (and its not booting). Any idea how to proceed? Any other values I can change? Anything else I can do? Is there another process?
 
#75 · (Edited)
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.
 
#78 ·
Damn, this was the only backup I had. I did not check, if its empty or values written to it. Obviously the CH341 Programmer Tool showed me that reading was possible and it stored a file (but empty). That`s why I assumed my connection was ok. But it seems that the clip was not attached correctly to the chip. So I have no original backup anymore :-(

I now have HxD as HEX Editor.

I correctly flashed the rescue.bin (without any changes) and the cmu is still dead and no signs of life via putty/serial access visible - same after I changed the value FF to 00 in line 010000 -> cmu is still dead. I guess the issue is not the SPI NOR chip, but another hardware failure?

Thanks a lot craz for all the help & info!
 
#79 ·
I have a second CMU here with 70.00.352 EU on it (working). I made a backup of its SPI NOR chip and copied it to the dead CMU. The CMU still keeps playing dead (no display/no serial activity). Same result when I patched the value 00 to line 10000 to this backup. Please find these two files attached:
So I guess this CMU is really dead and can not be revived via SPI NOR flashing.
 
#85 · (Edited)
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.
 
#88 · (Edited)
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.
 

Attachments

#90 ·
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.
 
#94 ·
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.
 
#113 ·
No, I have never seen such a new CMU (with FW 70 or above from factory) doing a downgrade. But to my knowlegde Mazda only stated, that the brand new CMUs (74.00.200 from factory) should not be downgraded. So my assumption is, that your .337 CMU should be downgradeable to .100 ot .502.
 
2004 to 2020 Mazda 3 Forum and Mazdaspeed 3 Forums
posts
642K
members
141K
Since
2008
Come discuss all things Mazda 3 from the Mazda GT hatchback to Mazdaspeed, sedan and sport.
Full Forum Listing
Explore Our Forums
2014-2018 Mazda 3 Skyactiv Audio & Electronics 2014-2018 Mazda 3 Skyactiv Discussion 2010-2013 Mazda 3 & Skyactiv Discussion New Member Introduction & Forum News/Guide 2014-2018 Mazda 3 Skyactiv Appearance & Interior