MicroHacker Forum

A while ago i did update an MCA with ServicePack 2015 and after done, it won't turn on the display anymore. The mainboard unit runs well, and if i swap the graphicsboard everything works. It seems the update bricked the graphicsboard.

Any ideas here?

I would try to desolder the flash (for heavens sake this one is TSOP-48 and not BGA...) and put a flash chip of s working device onto it, in case only the content is damaged.

Start the update with the good Screen then still during the update of the main board (OMAP CPU), swap the screens and let it finish the update process.

I did this in the past with a DVD NX - I was playing around with FW versions - with or W/O camera and flashed a camera FW to a screen without it, so the screen was bricked (Altera I - no camera vs Altera II with camera - for old NX - those with DVD) and I was able to recover it using this "trick".

Pretty cool tip, @dgalexandru, i'll try that!
This may heal the firmware in the graphicsboard flash without desoldering it. Because of the massive mass layers around the flash, it's really a pain to unsolder and resolder them. I did this once on a spare board and found that the pads will loose up because of the heat impact needed to melt the tin.

Therefore i was looking for an approach to do this via the JTAG-Interface of the graphicsboard. Unfortunately i did not came very far. I managed to identify the pins and also could see the JTAG-ID (the Altera Cyclone) but could not do anything. The reason is that a FPGA does not have a common interface for the Flash, it is made by the "structure" of the FPGA and this is hidden. So you need to know what the FPGA forms (usually some kind of CPU) and how to bring software into the RAM and let the CPU execute it which then accesses the Flash chip and sends it's data over the JTAG wire to the interface. This is not a trivial task because you need to write the software yourself...

Oh, by the way, one thing about the camera stuff. The NX is different from the MCA since there are specialised boards having the Video ADC. On the MCA the boards are the same but only the parts are missing. But for all of them (even the FX) the software is the same on devices with or without Video.
You can plug a video enabled graphics board onto a non-video mainboard and still get video if you apply the signal on the pads of the mainboard.

The Altera I (EP1...) was used on the FX devices only. The NX uses Altera Cyclone II (EP2...) and the MCA Cyclone III (EP3...).

I know that the firmware on the graphicsboard needs to "match" the firmware of the mainboard somehow. If not you get strange text messages and screen layouts, but everything works. But they will always show a picture. So for the boards not showing a picture anymore i expect the firmware was not completly written, as they worked before the update.

DGAlexandru wrote: ↑18 Aug 2019, 09:40 Start the update with the good Screen then still during the update of the main board (OMAP CPU), swap the screens and let it finish the update process.

I've tested this yesterday with an FX, which had the same problem but could not successfully follow your suggestion. After i removed the working front and put on the defective one, the unit seem to run for a minute or so and then CD stops. I've waited half an hour but it does not change.

Maybe my trick works only on NX... or my bad screen was still working on the BUS side with the WatchDog and OMAP, but not giving anything on the display.

We should test and see what happens with a FX unit when it is ON and you remove and put back the screen and then the same with a NX unit... and try to understand if there are diferences.

I'll try. On an FX i can tell that it won't automatically start up after putting it back, but if you push the ON-Tipper it seems to start without issues.

Hi,
in february, I played with the graphics board firmware on my test FX device. The update failed and the graphics board stopped working.

Today, after a long break, I tried to restore the graphics board using this trick. And I was successful! I can confirm that this trick also works on FX!

It worked until several attempts, I finally tried to turn on the device with the new board, then inserted a old one, then the new one again, and then a old one again, and it worked!

By the way, can anyone help with the connection to the S29GL064N90TFA02 Spansion 8 MB Flash-Memory on the graphics board? For example via JTAG without desolder the chip?

No Flash is directly connected to JTAG, it's always "throught" a processor. The problem is that the "CPU" is build by the Cyclone FPGA and the IP stored in an external EEPROM. So no one knows what this CPU is and therefore cannot stop and upload software into it's RAM to deliver the Flashs contents through JTAG.

Go4IT wrote: ↑08 Sep 2020, 18:25 No Flash is directly connected to JTAG, it's always "throught" a processor. The problem is that the "CPU" is build by the Cyclone FPGA and the IP stored in an external EEPROM. So no one knows what this CPU is and therefore cannot stop and upload software into it's RAM to deliver the Flashs contents through JTAG.

Now I have some time after a long time. I have the wires connected from JTAG to the graphics board. I tried to set up "Project" and establish a connection but without success.

Settings : I suppose, that the motherboard may not be connected when Jlink has a separate power supply.

Thanks for the tips.

I don't think we could do anything with the Segger here, because the JTAG is connect to the Altera Cyclone FPGA, which is not a directly useable device. The chip itself needs to load a program (IP) from an external Flash/EEPROM to form "anything". I guess this IP will setup some kind of RISC CPU, but until then it's just a dump piece of hardware. The external Flash where the graphicsboard firmware resides is only connected to some IO-ports of this FPGA. So Segger would need to have a bootcode to build the needed data reader/writer on an FPGA.

If you use Altera Software (FPGA Builder) it is possible to connect to the Cyclone, but this software is not ment to access any external Flash. So you get stuck here also.

My only hope was (is) that the virtual CPU, which is build on boot on the FPGA-Hardware, comes with some JTAG support, so it uses these pins and is able to execute arbitrary RISC code over it.