Gauge Sweep im vFL Convers+

Ich mach mich mal auf die Suche nach dem "Gauge-Sweep", also dem Vollausschlag eines Zeigerinstrumentes im Convers+.

Dieser wird z.B. als erstes ausgelöst wenn man sich ins das Service-Menu begibt, kann jeder selbst mal testen.

Also wird es irgendwo in der Firmware des Convers+ eine Routine geben die die Nadeln auf Vollausschlag und zurück ansteuert.

Die Nadeln im Tacho werden über Schrittmotore auf die gewünschte Position gefahren. So ein Schrittmotor hat für gewöhnlich 4 Anschlüsse. Auf die Funktionsweise eines solchen Motors möchte ich hier nicht eingehen, es gibt genügend Informationen und Videos dazu im Netz. Nur grob: Im Gegensatz zu einem herkömmlichen Motor bewegt sich der Schrittmotor nur ein kleines Stück (Winkel). Diese Schrittweite ist immer gleich und dadurch weiss man auch ohne Positionsrückmelder wo sich die Motorachse danach befindet. Die Ansteuerung erfolgt in einer gewissen Sequenz der Spulen und das Timing sowie die Phase bestimmen die Geschwindigkeit und Drehrichtung.

Eine einfache Durchgangsmessung mit den Anschlüssen am Schrittmotor der Drehzahlnadel (links) führt mich zu einem 24-poligen Controller-IC:

Dieser ist mit "SCZ900541EG" beschriftet und vom Firmenlogo her von Freescale (2015 von NXP aufgekauft). Die Bauteile mit "S" am Anfang sind allesamt Custom-Chips und wie erwartet finde ich kein Datenblatt dazu im Netz. Also schaue ich mal mit dem guten alten Durchgangsprüfer wie das Ding belegt ist...

Die beiden Schrittmotor-Treiber werden also über die DSPI_A Schnittstelle vom MAC7116 angesteuert, also mittels dem SPI Protokoll. Dabei sind beide Chips kaskadiert (Daisy Chain), der MAC bildet den SPI-Master und die beiden Treiber die Slaves, wie hier exemplarisch mit drei Slaves dargestellt:

[Blockierte Grafik: https://upload.wikimedia.org/wikipedia/commons/9/97/SPI_three_slaves_daisy_chained.svg]

Hier in dem Schaubild der SPI-Kommunikationsstruktur vom MAC erkennt man das es einen FIFO (Stack) gibt, sowohl zum senden als auch zum empfangen:

D.H. will die Firmware etwas zu diesen Stepper-Controllern per SPI senden, legt sie die zu sendenden Bytes in den Sendebuffer "TX FIFO" und der Chip kümmert sich dann um die Übertragung. Umgekehrt, kommen Daten vom Stepper-Controller am MAC an, landen diese zunächst im Eingangspuffer "RX FIFO". Dabei kann der interne SPI-Controller sowohl einen Interrupt auslösen um die Firmware-Routine zur Verarbeitung der Daten aufzurufen, oder diese direkt an einen Speicherbereich im RAM schreiben (DMA).

Mich interessiert erstmal wie die Firmware diese Controller initialisiert und anspricht. Hierzu muss sie sich des Memory-Mapped-IO der SPI-Schnittstelle bedienen. Das Datenblatt des MAC zeigt, das der IO-Bereich des DSPI_A ab 0xFC0B4000 beginnt. Das Datenblatt gibt die Register relativ zu dieser Basisadresse an:

In jedem Fall müsste die Firmware den SPI-Controller initialisieren, also auf das "DSPI Module Configuration" Register zugreifen. Dieses hat die Adresse 0xFC0B4000.

Aber auch 0xFC0B4034 ist interessant, denn da liegt das "DSPI Push TX FIFO" Register. Ein Byte welches an diese Adresse geschrieben wird, kommt in den Sendepuffer.

Also begebe ich mich mal in die Untiefen der Firmware, disassembliere diese und versuche draus schlau zu werden und tatsächlich hab ich rasch eine heiße Spur:

ROM:0001AD06 ; =============== S U B R O U T I N E =======================================
ROM:0001AD06
ROM:0001AD06
ROM:0001AD06 sub_1AD06                               ; CODE XREF: sub_19AFA+8↑p
ROM:0001AD06                 PUSH    {R6,R7,LR}
ROM:0001AD08                 PUSH    {R3-R5}
ROM:0001AD0A                 LDR     R5, =0xFC000000
ROM:0001AD0C                 MOVS    R0, #0xB4000
ROM:0001AD10                 ADDS    R4, R5, R0
ROM:0001AD12                 LDR     R0, [R4]
ROM:0001AD14                 MOVS    R6, #1
ROM:0001AD16                 ORRS    R0, R6
ROM:0001AD18                 STR     R0, [R4]
ROM:0001AD1A                 LDR     R1, =unk_E8040
ROM:0001AD1C                 MOVS    R0, #0x6C ; 'l'
ROM:0001AD1E                 ADDS    R7, R5, R1
ROM:0001AD20                 STRH    R0, [R7,#0xA]
ROM:0001AD22                 MOVS    R0, #1
ROM:0001AD24                 BL      sub_7206
ROM:0001AD28                 LDR     R1, =unk_E8040
ROM:0001AD2A                 MOVS    R0, #0
ROM:0001AD2C                 ADDS    R1, #0x20 ; ' '
ROM:0001AD2E                 ADDS    R5, R5, R1
ROM:0001AD30                 STRB    R0, [R5,#0xD]
ROM:0001AD32                 MOVS    R0, #8
ROM:0001AD34                 BL      sub_7206
ROM:0001AD38                 STRB    R6, [R5,#0xD]
ROM:0001AD3A                 MOVS    R0, #0x80
ROM:0001AD3C                 STRH    R0, [R7,#0xA]
ROM:0001AD3E                 MOVS    R0, #1
ROM:0001AD40                 BL      sub_7206
ROM:0001AD44                 LDR     R0, [R4]
ROM:0001AD46                 BICS    R0, R6
ROM:0001AD48                 STR     R0, [R4]
ROM:0001AD4A                 POP     {R3-R7}
ROM:0001AD4C                 POP     {R3}
ROM:0001AD4E                 BX      R3
ROM:0001AD4E ; End of function sub_1AD06
ROM:0001AD4E

In dieser Funktion wird das CPU-Register R5 mit dem Wert 0xFC000000 geladen (LDR), anschließend R0 mit dem Wert 0xB4000 (MOVS). Dann wird R0 zu R5 addiert und das Ergebnis nach R4 gespeichert (ADDS):

ROM:0001AD0A                 LDR     R5, =0xFC000000
ROM:0001AD0C                 MOVS    R0, #0xB4000
ROM:0001AD10                 ADDS    R4, R5, R0

Heraus kommt das in R4 nun der Wert 0xFC0B4000 gespeichert ist, also genau der gesuchte Offset zum SPI-Controller.

Was dann im Code folgt muss ich noch analysieren. Dort werden Daten aus dem SPI-Controller in den RAM geschrieben, bzw. verglichen. In jedem Fall ist aber klar das diese Funktion etwas mit SPI zu tun haben muss.