Bricked MCA-Plus graphicsboard

ACM - Ford FX, NX and MCA headunits
Post Reply
Go4IT
Pro
Posts: 966
Joined: 08 Feb 2019, 12:25

Bricked MCA-Plus graphicsboard

Post by Go4IT »

Hi folks,

i've been sent a MCA-Plus graphicsboard which does not show any graphics and tried to get the failure.

After a visual inspection (looking for burned or ripped off parts) i spend some hours comparing measurement-points (MP...) on the defective board with a working one. In powered, but not switched-on status (so only apply power to the mainboard but not press the on-tipper button), both setups show a power consumption of 720 mA. In this status the mainboard would powerdown the whole system after some minutes, but i compared nearly all MPs on both boards and in this status they seem equal.

When pushing the on-tipper button, the defective board only raises power draw by ~40 mA where the working board puts 100 mA power draw. Again i compared the MPs of both setups and it turns out that the LCD-part of the defective board does not get any enable signals (all LOW).

Then i've swapped the Flash-Chip in case it had a problem and prevents the graphics-CPU from booting, but the Flash from the defective board runs without issues on the working board. After that i did the same with the FPGA IP-Flash "EPCS4" (this programs the Cyclone-III FPGA to form a custom CPU, running NIOS), but again, no change. So both parts and their contents are ok. Then i desoldered the Video ADC, just in case it has a failure, but that did not change anything. After that i changed the RAM-Chip (it is a Micron, you know ;-) but that also did not make any change. Changing the FPGA itself is not that easy, because it is BGA, so for now i skipped this.

I looked at the RESET signals and found out that the graphicsboard is periodically resetted by the mainboard. I guess the HMI software running on the OMAP expects some "livesign" from the graphicsboard, which does not happen and so it resets it after some seconds.

There is a SPI communication-channel going from the OMAP directly to the FPGA. I monitored the communication, but could not decode anything yet. The comm on the working board seems always be the same, but is different from the defective one.

On the good board the initial sequence looks like this:

Code: Select all

Time [s],Packet ID,MOSI,MISO
1.185084937500000,0,0x53,0x21
1.185089375000000,0,0xFF,0x98
1.185093750000000,0,0x00,0x03
1.185098187500000,0,0x00,0x20
1.185102625000000,0,0x00,0x18
1.185107000000000,0,0x00,0x60
1.185111437500000,0,0x00,0x20
1.185115875000000,0,0x00,0x60
...
1.666276312500000,0,0xAD,0x02
1.667670812500000,0,0xD0,0x68
2.590139625000000,0,0x53,0x21
2.590144062500000,0,0xFF,0x98
2.590148500000000,0,0x00,0x02
2.590152875000000,0,0x00,0xA0
2.590157312500000,0,0x00,0x18
2.590161750000000,0,0x00,0x60
2.590166125000000,0,0x00,0x20
2.590170562500000,0,0x00,0x6C

MOSI and MISO are the both communcation directions, one is from the OMAP to the FPGA and the other is the opposite direction.

On the bad board this sequence looks like:

Code: Select all

Time [s],Packet ID,MOSI,MISO
0.040990583333333,0,0x53,0x00
0.040995000000000,0,0xFF,0x00
0.040999416666667,0,0x00,0x00
0.041003833333333,0,0x00,0x00
0.041008250000000,0,0x00,0x00
0.041012666666667,0,0x00,0x00
0.041017083333333,0,0x00,0x00
0.041021500000000,0,0x00,0x00
...
0.041268916666667,0,0xAD,0x00
3.164769875000000,0,0x43,0x00
3.164774291666667,0,0x32,0x14
3.164778708333333,0,0x14,0x20
3.164783125000000,0,0x40,0x90
3.164787541666667,0,0x30,0x83
3.164791958333333,0,0x49,0x80
3.164796375000000,0,0xC9,0x80
3.164800791666667,0,0x01,0x80
It's clear to see that only one side is sending, but the other side does not respond. But after a while there is some backwards communication, so it seems like it is not completely dead.

For me it looks like the graphics-CPU can't initialize completely, maybe missing some external signal or other prerequisite and so can't get into the normal serverloop. But i've currently got no clue where to look next...
Go4IT
Pro
Posts: 966
Joined: 08 Feb 2019, 12:25

Re: Bricked MCA-Plus graphicsboard

Post by Go4IT »

After looking into some data scans of the communication i found out that there is a communication frame of 65 bytes.
Unused areas are filled with 0x00 on MISO and MOSI.
The frame ends with 2 bytes, wheres the last MOSI byte is always 0xD0.
Post Reply