Navigationssystem MCA startet nicht mehr

Habe mal wieder einen Patienten auf dem Tisch, ein MCA aus einem Kuga Facelift. Leider weiss ich zuwenig über die Plattform, aber ich gehe davon aus das der Kuga auch im FL an der Focus-Plattform angelehnt ist. Auch dort gab es ja nach dem NX das MCA. Im vFL Focus gab es immer das Problem mit der Tastenbeleuchtung, weil der Focus hier ein PWM Signal lieferte und die Mondeo-Geräte das ignorierten weil sie die Lichtintensität/Aktivität als CAN-Botschaft erwarteten. Also noch keine Ahnung ob man im Kuga FL ein Mondeo MCA verbauen könnte (geänderte Front natürlich). Aber egal, das ist auch nur eine Randinformation.

Das MCA startet nicht mehr. Das Front-End ist ok, es läuft an einem anderen Backend. Das Backend allein zieht ca. 100 mA Strom bei 12V, was bedeutet das nur der OMAP läuft und irgendwas das booten verhindert.

Die Firmware habe ich schon durch eine gekannte, funktionierende ersetzt => ohne Erfolg, daran lag es nicht.

Auch die RAMs habe ich, obwohl es bei der MCA Serie nicht mehr vorkam, probeweise ersetzt => ohne Erfolg, daran lag es auch nicht.

Die Spannungsversorgungen sind auch alle ok (es gibt div. Spannungsregler mit Hilfsspannungen für alles Mögliche) => alle ok

Die HW-Reset Bausteine überprüft => alle ok

Die Spannungsüberwachungslogik (Low-Power) überprüft => alle ok

Die Schaltlogik zum aktivieren der div. Komponenten überprüft => hier fehlen zwei wichtige Signale, welche vom OMAP kommen

Dann habe ich mich via JTAG mit Segger J-Link zum OMAP verbunden um evtl. herauszufinden ob die CPU läuft und was sie gerade tut. Damit meine Untersuchungen nicht durch die "Wachhunde" gestört wird, müssen die erst zurück in den Zwinger, also Watchdogs abschalten. Einmal den des Radioprozessors (V850) durch auf GND ziehen seiner /RESET-Leitung (ist ja bekannt, wird beim flashen auch benötigt) und einmal durch deaktivieren des OMAP-Watchdogs mittels beschreiben der Register:

connect
halt
write4 0xFFFEC808 0xF5
write4 0xFFFEC808 0xA0
write4 0xFFFEB048 0xAAAA

Interessanterweise scheint der OMAP nach einem Reset (z.B. durch ein "halt", "setpc 0" und "go", aber auch HW-Reset) immer wieder in einen ABORT mode zu gelangen:

J-Link: ARM9 CP15 Settings changed: 5327F from 78, MMU On, ICache On, DCache On
PC: (R15) = FFFF000C, CPSR = 000000D7 (ABORT mode, ARM FIQ dis. IRQ dis.)
Current:
     R0 =00000003, R1 =9014D818, R2 =2C28D86C, R3 =00070F7C
     R4 =90000014, R5 =2000FE28, R6 =00000000, R7 =0000001C
     R8 =00000040, R9 =FFF6FACD, R10=3BFF97FE, R11=00040034, R12=00000000
     R13=BBE9D6AB, R14=00000002, SPSR=000000F7
USR: R8 =00000040, R9 =FFF6FACD, R10=3BFF97FE, R11=00040034, R12=00000000
     R13=4BDFFB35, R14=FE7B70FF
FIQ: R8 =F819FD75, R9 =EBCD07F7, R10=F9DFA3D6, R11=F7FFAFF7, R12=CE7FBED9
     R13=F3FBFD73, R14=67EEFFF1, SPSR=00000010
IRQ: R13=FEBED7DA, R14=F46E7BFE, SPSR=00000010
SVC: R13=2000FE18, R14=00001FA0, SPSR=00000010
ABT: R13=BBE9D6AB, R14=00000002, SPSR=000000F7
UND: R13=9FF77F7B, R14=BF7DFFD1, SPSR=00000010

Man sieht gut das der PC immer auf 0xFFFF_000C steht, was dem Reset-Vector von ABORT entspricht. Auch der aktuelle CPSR-Mod (ABORT mode) spricht dafür. Das Datenblatt sagt dazu

EMIFS Abort Control

In case of access restriction violation, and in case of access time-out errors, the EMIFS can handle an interrupt line and abort status register to allow abort events system monitoring.

Abort Management

The EMIFS can issue an interrupt in two cases of abort scenario:

Restricted access mode violation on CS0

Access to CS0 address space is limitted to the MPU

When an access to CS0 space is initiated by the DMA, the DSP, or the OCP-I, the EMIFS completed the access giving back a 0 value as read value or without writing the given value to the final destination.

The EMIFS raises a TC abort interrupt (IRQ_ABORT) sets the abort flag bit, sets the restricted access error status bit, and updates the host ID bit field in the abort type register. The EMIFS updates the abort address register with the requested address causing the access violation.

The abort flag bit is cleared when the abort type register is read.

Time-out issue during any access in case of full-handshaking mode

This feature can be enabled with the TIMEOUT_EN bit field and with an 8-bit TIMEOUT programmable value (expressed in REF_CLK cycles) in the EMIFS abort time-out register (see Table 12).

On beginning of an access, the time-out counter starts counting down. If the counter reaches 0 before the device response, the EMIFS raises an interrupt, sets the abort flag bit, sets the time out error status bit and updates the host ID bit field in the abort type register. The EMIFS updates the abort address register with the requested address causing the access time out.

The abort flag bit is cleared when the abort type register is read. At reset, TIMEOUT_EN is set to 1 and time-out value is set to 255 REF_CLK cycles.

Also ist es nicht nur bei Zugriffsverletzungen, sondern auch dann wenn etwas nicht in einer erwarteten Zeit antwortet (Timeout). Das klingt interessant. Meine These aktuell ist das genau das die Firmware davon abhält vollständig hochzufahren. Oder aber der Code kommt in eine Situation wo er selbst diesen Abort auslöst. Nun gilt es heraus zu finden wo dies geschieht und warum?

The type of the abort event is reported in a status register.

Base 0xFFFE CC00
OCPT1_ATOR OCP-T1 abort time-out R/W 0xAC
OCPT1_AADDR OCP-T1 abort address R 0xB0
OCPT1_ATYPER OCP-T1 abort type R 0xB4

OCPT2_ATOR OCP-T2 abort time-out R/W 0xE0
OCPT2_AADDR OCP-T2 abort address R 0xE4
OCPT2_ATYPER OCP-T2 abort type R 0xE8