Auf einem nicht funktionierenden Bluetooth-Modul eines Ford (8M5T-19C112-BK) befindet sich neben einigen bekannten Chips (DSP, Bluetooth, etc.) u.a. folgender Chip im LQFP-144 Gehäuse wie auf dem Bild zu sehen, beschriftet mit "NS" und "CP3CN37VVAWQ". Nach meiner Recherche ist das ein der CP3CN37-Serie von National Semiconductor, welche wohl irgendwas von Texas Instruments aufgekauft wurden. Als Datenblatt habe ich nur eines für den CP3CN17: http://www.alldatasheet.com/datasheet-pdf/pdf/125964/NSC/CP3CN17.html Ich denke das der von der Funktion dem CP3CN7 ähnlich ist, aber das Pinout stimmt natürlich nicht da der CP3CN17 im LQFP-100 und der CP3CN37 im LQFP-144 Gehäuse daher kommt. Das Modul zieht ca. 70 mA Strom, gibt aber keine CAN Botschaften von sich und reagiert auf auch keine, was ein funktionierendes Modul macht. Meine Vermutung geht in Richtung defekte Software. Auf dem Board befinden sich auch einige Messpunkte und Aufdrucke, einer mit "MCU_DEBUG". Leider finde ich zu dem o.g. Chip kein Datenblatt, womöglich wieder einer dieser zahlreichen Custom-Chips. Die drei Flash Bausteine habe ich bereits entlötet und ausgelesen. Aufgrund der dicken Masseplanes ist das entlöten und löten rein mit Lötkolben oder Heißluft etwas murksig... Interessant finde ich, das die Abkürzung "CP3C" auch im Radiosystem des Ford häufig vorkommt.
Angehängte Dateien:
-
b1549218978.35170.jpg
260 KB -
b1549218978.35181.jpg
240 KB -
bt-module_pcb_bottom.jpg
230 KB
:
Bearbeitet durch User
Nachdem es den Chip auch bei Digi-Key gibt denke ich nicht das es ein kundenspezifischer Chip ist. Bei einigen Chips bekommt man die Datenblätter allerdings nur unter gewissen Auflagen direkt vom Hersteller (NDA).
Anfrage bei TI läuft, aber den Ausgang erahne ich bereits... :-( Automotive-Zeugs wird behandelt wie Staatsgeheimnisse. Evtl. gibt es ja einen Chip der pinkompatibel ist. Manchmal unterscheiden sich die Versionen ja nur in RAM und Flash-größe. Das wär meine Hoffnung.
Antwort von TI war erwartungsgemäß negativ. Die behaupten dieses Bauteil garnicht (mehr) zu kennen :-|
Hier ein link zum Schaltplan: https://4donline.ihs.com/images/VipMasterIC/IC/TXII/TXII-S-A0004907077/TXII-S-A0004907077-1.pdf?hkey=52A5661711E402568146F3353EA87419
Peter schrieb: > Hier ein link zum Schaltplan: > https://4donline.ihs.com/images/VipMasterIC/IC/TXII/TXII-S-A0004907077/TXII-S-A0004907077-1.pdf?hkey=52A5661711E402568146F3353EA87419 Extreeeem coool, viiielen Dank!!!! :-)))
Mal kurz zum Status meines Projektes, welches dank des Datenblattes, welches ich nun durchgearbeitet habe, deutliche Fortschritte macht: Mich interessiert zunächst der Bootmodus von dem Chip. Hier sind die externen Signale von ENV0 und ENV1 entscheident, ob vom internen ROM (16kb) oder vom externen Memory (Flash, bis zu 4MByte insgesamt über max. 2 CEs) gebootet wird. Mit ihnen wird auch der Einstiegspunkt festgelegt: ENV1 ENV0 Operating Environment Reset Vector 0 0 ROM32 mode 00FE 0000h 1 1 ERE16L mode 0040 0000h 1 0 ERE16H mode 0080 0000h Das interne ROM dient nur dazu einen zweiten Bootloader (SBL) nachzuladen, entweder über USB oder UART. In Normalfall soll mein Modul vom Flash booten. Dies tut es möglicherweise nicht mehr. Ein Update wird bei dem Modul per USB eingespielt, sprich man steckt einen entsprechend bespielten Stick ein, schaltet das Gerät und damit das Modul an und los gehts. Auch das tut es derzeit nicht. Eine Idee wäre die Pins ENV0 und ENV1 auf "0" zu setzen um das Modul zu zwingen den internen Bootloader zu starten, welcher dann per USB oder UART eine Software erwartet. Ich müsste dann noch wissen in welchem Format das vorliegen soll und natürlich die entsprechende Software besorgen. Die Mnemonic der Assemblerbefehle ist im Datenblatt vorhanden. Sie basiert auf der RISC Architektur. Ich würde dann mal versuchen was IDA dazu sagt... Um den Fehler im Modul zu finden ist natürlich Debugging eine tolle Sache. Hierfür unterstützt der Chip laut DB JTAG, Hardwarebreakpoints. Leider ist nicht beschrieben wie, also gehe ich davon aus das es einen "Standard" dafür gibt der implementiert wurde. Um die Flash-Speicher über den JTAG-Port des uC auszulesen und zu beschreiben wird eine Hilfssoftware notwendig sein, welche per JTAG ins SRAM vom Chip geladen und ausgeführt werden muss. Ich hoffe für den Chip eine Unterstützung beim Segger J-Link zu finden.
Angehängte Dateien:
-
env0_env1.jpg
150 KB
So, CS0 für den externen Speicher geht an den /CS von Flash 3, rechts neben dem CP3CN37 auf der Platine. CS1 scheint nicht belegt. Somit ist klar das dieser 2 MByte große Flash die Software für den CP3CN37 enthalten muss. Habe den mittels TL866 ausgelesenen Dump angehangen. Die Pins ENV0 und ENV1 sind nicht statisch belegt sondern werden über Transistoren geschaltet (siehe Bild). ENV0 ist dabei anfänglich LOW und wird nach ca. 1 Sekunde HIGH. ENV1 ist erstmal LOW und nach ca. 1 Sekunde sieht es aus als wäre doch eine hohe Frequenz. Laut Datenblatt hat der Pin mehrere Funktionen, u.a. PLL. Gut möglich das er nach dem Reset umkonfiguriert wird. Aufgrund des Startmodus von ENV0 und ENV1 müsste der Chip also vom internen ROM booten. Dabei wartet er laut Datenblatt eine Sekunde lang ob auf USB oder UART etwas verbinden will. Das würde die oben gemessene Verzögerung erklären. Nach einer Sekunde werden die Pins dann für etwas ganz anderes umprogrammiert. Nehmen wir an das ist so, dann stelle ich mir die Frage was nach dem ausführen des Bootloaders geschieht? Der ROM-Code ist laut Memorymap an Adresse 0xFE0000 und 16 KByte groß. Danach wird er irgendwo hinspringen, das ist aber nicht erwähnt. Ich vermute das er dann die Programmausführung ab 0x00 0000 beginnt, wie das sonst so übich ist? Ab dieser Adresse liegt dann das Flash. Also müsste ab dem Anfang valide RISC Maschinenbefehle stehen. Achja, die JTAG-Pins habe ich inzwischen auch ermitteln können.
:
Bearbeitet durch User
Olli Z. schrieb: > Nehmen wir an das ist so, dann stelle ich mir die Frage was nach dem > ausführen des Bootloaders geschieht? Der ROM-Code ist laut Memorymap an > Adresse 0xFE0000 und 16 KByte groß. Danach wird er irgendwo hinspringen, > das ist aber nicht erwähnt. Ich vermute das er dann die > Programmausführung ab 0x00 0000 beginnt, wie das sonst so übich ist? Ab > dieser Adresse liegt dann das Flash. Also müsste ab dem Anfang valide > RISC Maschinenbefehle stehen. Auf den ersten Blick sieht es so aus als ob da etwas sinnvolles im Flash steht, zumindest ist der Anfang davon gueltiger CR16C Code. Das muss aber nicht viel bedeuten, falls wirklich irgendwo im Flash Bits gekippt sein sollten, wuerde das ja ausreichen damit es Probleme gibt.
Danke für die Info Dieter! Mit welchem Disasm bist Du denn da ran gekommen? Ich nutze für sowas gern mal https://disassembler.io aber der erkennt keinen Code darin. Laut Datenblatt stimmt das mit der CR16C CPU (CompactRISC, 16 Bit). Über den Endiantyp schweigen die sich aus, aber der externe Datenbus arbeitet Little-Endian, dann wird das auch für die CPU so sein. Die Startadresse vom Flash könnte 0x40 0000 sein. Ab Offset 0x2000 kommt auch etwas lesbarer Text:
1 | Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
2 | 00002000 49 42 4C 20 56 20 31 2E 32 31 30 0A 32 33 2D 30 IBL V 1.210.23-0 |
3 | 00002010 37 2D 30 38 0A 52 58 2D 34 32 0A 48 57 36 30 0A 7-08.RX-42.HW60. |
4 | 00002020 28 63 29 20 4E 4F 4B 49 41 (c) NOKIA |
:
Bearbeitet durch User
Olli Z. schrieb: > Danke für die Info Dieter! Mit welchem Disasm bist Du denn da ran > gekommen? Ich nutze für sowas gern mal https://disassembler.io aber der > erkennt keinen Code darin. Fuer IDA Pro gibt es ein Prozessor Modul für den CR16C, das ist allerdings nicht vollstaendig. Wenn man sich die Strings im Firmware Binary ansieht findet man Hinweise auf einen EEPROM. Falls tatsaechlich ein externer EEPROM angeschlossen ist und nicht der Flash gemeint ist, koennte natuerlich auch dort die Ursache fuer die Probleme liegen.
Dieter schrieb: > Fuer IDA Pro gibt es ein Prozessor Modul für den CR16C, das ist > allerdings nicht vollstaendig. Das habe ich zwar auch gefunden: https://github.com/krater/CR16C-IDA-Pro-Plugin Ist aber nur als Sourcecode für die IDA Pro Edition verfügbar. Das schreibt Hexrays auch auf ihrer Homepage "NSC CR16 (comes only with source code)". (https://www.hex-rays.com/products/ida/processors.shtml bzw. https://www.hex-rays.com/products/ida/gallery/index.shtml) Und um das compilieren zu können benötigt man die IDA SDK, welche ebenfalls nur für die Pro Edition erhältlich ist. Zudem schreibt der Autor des Plugins im Readme "At the moment only some opcodes supportet...to be continued..." und, naja das ist von 2011 also wird da eher nichts mehr $continued" ;-) Also heißt es wohl einen anderen Disassembler zu finden. IAR Workbench könnte da vielleicht helfen, ist aber extrem teuer. Die Frage ist warum ODA (https://disassembler.io) zwar CR16C anbietet, es aber mit meinem BIN file nichts anfangen kann?! Dieter, womit hast Du denn nun erkannt das es sich um validen CR16C code handelt? Oder ist der Beginn des Dumpfiles noch gar kein Maschinencode sondern eine Interrupt-Vector-Tabelle? Oder womöglich sogar Daten und der Codeeinstieg liegt ganz woanders? Wie gesagt, habe noch keine Idee was der uC nach dem laden des BootROM so treibt und wie er letztendlich die Software vom Flash startet. Neben dem Flash ist übrigends auch noch ein 2MB großer RAM Chip am uC angeschlossen.
:
Bearbeitet durch User
Olli Z. schrieb: > Dieter, womit hast Du denn nun erkannt das es sich um validen CR16C code > handelt? Das habe ich doch bereits geschrieben (Ja, ich habe eine IDA Pro Lizenz und das SDK und kann damit das CR16C Prozessor Modul verwenden bzw. die fehlenden Dinge nachruesten). Ich sehe aber ehrlich gesagt nicht inwieweit es Dir weiterhilft wenn Du das Binary disassemblieren kannst, damit wirst Du vermutlich nicht sehen warum Dein Steuergeraet nicht mehr funktioniert. Die "MCU_DEBUG" Pins klingen interessant, die sind in der Naehe der UART Pins des Chip. Eventuell ist das ja eine Art Debug Konsole, die vielen Strings im Binary legen die Vermutung nahe dass es eine serielle Debug-Ausgabe geben koennte. Vielleicht gibt diese Konsole (falls eine vorhanden ist) ja irgendwelche interessanten Dinge aus.
Angehängte Dateien:
-
bt-module_jtag-pins.jpg
26 KB
Anbei erstmal die JTAG-Pinbelegung. Leider habe ich dort keinen RESET gefunden, aber den kann man natürlich auch mittels JTAG-Kommando auslösen. Ein Probe auf dem JTAG ergab:
1 | ConfigTargetSettings() start |
2 | ConfigTargetSettings() end |
3 | TotalIRLen = 8, IRPrint = 0x0001 |
4 | JTAG chain detection found 1 devices: |
5 | #0 Id: 0x0FB1501F, IRLen: 08, Unknown device |
6 | |
7 | ****** Error: CPU-TAP not found in JTAG chain |
8 | |
9 | Cannot connect to target. |
Zumindest scheint die JTAG-Chain funktionsfähig, wenn ich auch nicht weiss wie ich einen CR16C (RISC) mit Segger J-Link nutzen könnte. Unter der angegebenen ID finde ich auch kein registrierted Gerät und auch das Datenblatt von TI schweigt sich zu dem Thema aus.
Angehängte Dateien:
Nächster Versuch an der mit "MCU_Debug" gekennzeichneten Stelle. Auf dem Bild der TPs erkennt man das hier wohl noch Hilfsbauteile vorgesehen sind. Ein Widerstand vermutlich (rechts) und ein Transistor (links). Entgegen meiner Erwartung ist einer der Pins nicht GND sondern IOVCC (3.3V). Der andere ist das Signal, kommt aber nicht direkt vom uC sondern von einem Pegelwandler (74HC374), welchen man auf dem Bild mit der MPU rechts unten sieht. Der Eingang davon kommt interssanterweise vom Pin XA3, eigentlich ein Adress-Pin für externes Memory. Ich hätte hier eher einen UART erwartet... Der CLK vom 374 kommt übrigens vom Pin XA13 des uC. Aber, in der Tat kommt dort ein Signal. Habe einen Screenshot vom LA, sowie die LA-Daten als ZIP angehangen. Irgendwie sinnvoll sieht das jetzt noch nicht aus.
Dieter schrieb: > Das habe ich doch bereits geschrieben (Ja, ich habe eine IDA Pro Lizenz > und das SDK und kann damit das CR16C Prozessor Modul verwenden bzw. die > fehlenden Dinge nachruesten). Kannst Du mir dieses Plugin irgendwie zukommen lassen? > Ich sehe aber ehrlich gesagt nicht inwieweit es Dir weiterhilft wenn Du > das Binary disassemblieren kannst, damit wirst Du vermutlich nicht sehen > warum Dein Steuergeraet nicht mehr funktioniert. Da magst Du schon recht haben, aber ich sammle einfach mal alles was mir irgendwann helfen könnte. Am meisten interessiert mich noch, wie der BOOT-Prozess abläuft und wann das externe Flash ins Spiel kommt und ab welcher Adresse, etc. Das habe ich gehofft mittels JTAG etwas genauer zu ergründen. Und vor allem an den Inhalt des Flash zu kommen. Ich habe nämlich noch ein intaktes Modul, will da aber die Flash-Chips nicht runterlöten (müssen), weil dies aufgrund der großen Masseflächen echt kritisch ist. Hätte beim anderen beinahe einen Pad abgerissen. > Die "MCU_DEBUG" Pins klingen interessant, die sind in der Naehe der UART > Pins des Chip. Eventuell ist das ja eine Art Debug Konsole, die vielen > Strings im Binary legen die Vermutung nahe dass es eine serielle > Debug-Ausgabe geben koennte. Vielleicht gibt diese Konsole (falls eine > vorhanden ist) ja irgendwelche interessanten Dinge aus. Sieht im Moment nicht so aus. Habe das auch mal an einem funktionierenden Modul gegen geprüft da beim defekten Modul derzeit garnichts raus kommt.
Angehängte Dateien:
-
TXD1.jpg
270 KB
Also, der CP3CN37 hat 4 UARTs. Die habe ich am funktionierenden Modul mal ausgemessen. Vor allem hat mich interessiert ob auch Aktivität am RX zu sehen ist, denn das wäre für mich ein Zeichen das dieser UART intern genutzt wird um peripherie anzusprechen. Dies war am UART0 (TXD0, RXD0) der Fall. Am UART2 und UART3 war gar keine Aktivität zu erkennen. Am UART1 hingehen gab es nur für kurze Zeit nach dem Systemreset Aktivität am TXD1 und nicht am RXD1, den schaute ich mir mittels LA näher an. Anbei die Aufzeichnung als ZIP, sowie die daraus gewonnenen Daten als CSV und BIN (abgetippt, weil ich nicht weiss wie man aus dem LA die reinen Daten als Binärstrom exportieren könnte). Beim LA habe ich einfach "Auto-Baud" eingestellt und es scheint mir das er es richtig erkannt hat. Zu erkennen sind Sequenzen unterschiedlicher Länge, jeweils gestartet mit 0x1E. Text ist darin nicht enthalten, das sind wenn reine Steuercodes, evtl. um eine Sitzung mit einem Debugger (Nexus?) zu initiieren.
:
Bearbeitet durch User
Nur mal so als Idee: Man findet Software Updates fuer ein aehnliches Steuergeraet, die per USB eingespielt werden (z.B. ford_audio_update_nov2012.zip). Wahrscheinlich gibt es die auch ganz offiziell vom Hersteller. Wenn man in diese Updates reinschaut sieht man schon anhand der Strings dass in dem Binary aus Deinem Flash einiges fehlt (als Anhaltspunkt z.B. der String "Classic Rock"). Könnte es sein dass ein Update abgebrochen wurde und deshalb einiges von der Firmware gar nicht im Flash gelandet ist? Falls dem so ist: Vielleicht findet man ja auch ein Update das genau zu der Version in Deinem Steuergeraet passt. Dann koennte man den Rest einfach in den Flash programmieren. Alternativ muesste man den Anfang der Updates im Flash suchen und die komplette Update Datei (ohne den Text Header) dort einspielen. Es koennte aber auch sein dass die Update Datei aus obigen ZIP Archiv das Update fuer eine Steuergeraete-Variante mit mehr Features ist und sie deshalb deutlich laenger ist. Aber falls man ein Software Update fuer genau Dein Steuergeraet findet koennte man zumindest den Flash Inhalt vergleichen.
Anderer Ansatz: Versorge das SG mit 12V an den Klemmen, und probier' mal die Diagnose nach ISO. -> https://wiki.muc.ccc.de/_media/asm:16:workshops:kfz_diagnoseprotokolle.pdf Könnte wetten, dass das Gerät sich schlafen legt, weil über den Can nichts kommt.
Also, erstmal vielen vielen Dank an Euch beide, ich weiss das wirklich zu schätzen das ihr mir so behilflich seit! Was ich eingangs nicht geschrieben habe ist, das ich mich mit CAN-Bus einigermaßen gut auskenne und selbstverständlich erst alle "gängigen" Rettungsversuche unternommen habe :-) Ja, das System wird normalerweise über seinen USB-Port mit Software versorgt. Diese Software habe ich selbstverständlich. Und ja, das Modul würde ohne CAN-Aktivität nach kurzer Zeit in den Deepsleep gehen, klar. Aber ich simuliere die Nachricht "Zündung AN" auf dem MM-CAN (Multimedia-CAN-Bus) und dann bleibt das Modul am leben. Wohl gemerkt, das funktionierende. Das defekte macht keinen Mucks am CAN, egal was ich sende. Weder auf DTC noch UDS noch normalen IDs rührt sich da was. Dennoch zieht es etwas Strom, wenn gleich auch nicht so viel wie das funktionierende. Das Problem mit der Software ist, das diese Updatesoftware, welche man bekommt, natürlich einen anderen Stand hat als die die auf dem Modul ist. Die Endung am Modul bestimmt Hardware/Feature- und Software-Release. *-BK bedeutet "B=Hardwarestand und aber auch Multilingual" und "K=Softwarestand". Die Software im Updatepaket für das Modul ist "U" und damit deutlich weiter. Aber ja, ich habe auch versucht heraus zu bekommen wo der Teil des CP3CN Flash im Updatepaket steckt, aber so recht passt da nix. Daher suchte ich ja nach einem Weg die Software vom Flash via JTAG vom funktionierenden Modul rauszulesen um die ins defekte zu programmieren. Das Modul hat aber auch leider nicht bei einem fehlgeschlagenen Update den Geist verloren, sondern "von jetzt auf gleich", was schon merkwürdig genug ist. Auf der Suche nach dem Fehler wollte ich nun wissen ob der Zentralprozessor läuft und arbeitet oder da das Problem bereits liegt. Daher meine Vorgehensweise.
Olli Z. schrieb: > Aber ja, ich habe auch versucht heraus zu bekommen wo der Teil des CP3CN > Flash im Updatepaket steckt, aber so recht passt da nix. Der Aufbau im Flash duerfte eventuell so aussehen: 0x000000 IBL (Initial Boot Loader?) 0x010000 PBL (Primary Boot Loader?) 0x080000 Application Die USB Software Datei (Endung .bvc bzw. .vbc) besteht aus einzelnen Teilen fuer die verschiedenen Komponenten (MCU, DSP, BT usw.). Der Marker fuer die einzelnen Teile ist "NSWUP" (plus Header mit weiteren Angaben). Dort findet sich fuer die MCU als Update der PBL und die "Application", aber auch ein SBL (Secondary Boot Loader?, eventuell nur zum Flashen noetig?).
Dieter schrieb: > Olli Z. schrieb: >> Aber ja, ich habe auch versucht heraus zu bekommen wo der Teil des CP3CN >> Flash im Updatepaket steckt, aber so recht passt da nix. > > Der Aufbau im Flash duerfte eventuell so aussehen: > > 0x000000 IBL (Initial Boot Loader?) > 0x010000 PBL (Primary Boot Loader?) > 0x080000 Application > > Die USB Software Datei (Endung .bvc bzw. .vbc) besteht aus einzelnen > Teilen fuer die verschiedenen Komponenten (MCU, DSP, BT usw.). Der > Marker fuer die einzelnen Teile ist "NSWUP" (plus Header mit weiteren > Angaben). Dort findet sich fuer die MCU als Update der PBL und die > "Application", aber auch ein SBL (Secondary Boot Loader?, eventuell nur > zum Flashen noetig?). Richtig. Es sind ja 3 Flashes im Modul verbaut, einer ist an der MCU und vermutlich einer am BT-Chip (CSR-BC417) und einer am DSP (TMS320). Das Update-File ist ca. 7MB groß (hier mal das 8M5T-14D511-BU angenommen weil es am besten passen würde). Ebenfalls angenommen das das Update-File auch wirklich die gesamte Software enthält und nicht bloß Patches :-) NSWUP ist wohl eine Abkürzung für "Nokia SoftWare Update" oder sowas ;-) In der genannten Updatedatei (ich betrachte jetzt nur den Binärteil, also ohne den VBF-Overhead der *.bvc Datei) finde ich das Kürzel an mehreren Positionen. Die von Dir genannten Adressen beziehen sich nun auf was genau?
Olli Z. schrieb: > Die von Dir genannten Adressen beziehen sich nun auf was genau? Das ist der Offset in das Flash-Image von Dir. Ich bin mir inzwischen relativ sicher dass es da auch noch einen seriellen EEPROM mit mindestens 8 KByte Groesse geben muesste, auf dem Bild kann ich die Bezeichnungen nicht erkennen um das zu verifizieren. Dieser EEPROM ist vermutlich fuer Fehlerspeicher und Speichern der Seriennummer usw. zustaendig. Ich koennte mir auch vorstellen dass der fuer das Problem verantwortlich ist, die Integritaet der EEPROM Daten wird geprueft. Falls es diesen seriellen EEPROM gibt waere der Inhalt interessant, im Vergleich dazu auch der Inhalt vom funktionierenden Steuergeraet.
Dieter schrieb: > Olli Z. schrieb: >> Die von Dir genannten Adressen beziehen sich nun auf was genau? > Das ist der Offset in das Flash-Image von Dir. Ich habe mal das genannte Update-File angehangen und zwar nur den Binary-Teil davon. Darin enthalten sein müsste wenigstens der Inhalt der 3 Flash-Chips vom Board. Ausser, einer ist nicht zum updaten gedacht... aber tun wir mal so. Die flash-Speicher sind ja nicht voll beschrieben, daher dürfte das schon stimmen. Auch glaube ich an die Theorie mit dem NSWUP-Trenner. Die gibt es aber doch eigentlich nur im Update-File und nicht im Dump?! Im Dump kann ich Deine Start-Adressen nicht nachvollziehen, oder war das nur eine Idee wie es sein könnte? > Ich bin mir inzwischen relativ sicher dass es da auch noch einen > seriellen EEPROM mit mindestens 8 KByte Groesse geben muesste, auf dem > Bild kann ich die Bezeichnungen nicht erkennen um das zu verifizieren. Ich schau das nochmal genau nach und mache eine Inventarliste aller Bauteile. Wollte ich ohnehin tun :-) Ja, ein Bootloader müsste im Updatefile enthalten sein, denn ohne wird das alles nicht funktionieren. Das Datenblatt gibt ja auch ganz klar an das der ROM-Bootloader (den würde ich mal als PBL, Primären Bootloader sehen) nur in der Lage ist über Serial oder USB eine Datei zu "Ausführung" anzuziehen. Um das flashen muss sich dann die ausgeführte Software selbst kümmern. Dieser Bootmechanismus arbeitet aber in beiden Fällen mit Steuerbefehlen und nicht mit Dateien. Ich denke daher das dies im funktionierenden Modul etwas anders läuft und da garnicht der ROM-BTL zum Einsatz kommt, sondern die auf dem MCU laufende Firmware. Die musst ja am USB Bus einen Datenträger erkennen und vor allem darin die richtige Datei anziehen.
Die Update-Datei 8M5T-14D511-BU.bin besteht aus 17 Teilen, fuer die MCU ist das drinnen: SBL MCU Offset: 0x000080 Size: 0x03FBFC PBL MCU Offset: 0x04664C Size: 0x070000 PBL MCU Offset: 0x0B66CC Size: 0x070000 Application Offset: 0x12674C Size: 0x170000 Warum es zwei PBLs gibt weiss ich nicht, die sind sich aber sehr aehnlich. Der SBL koennte eventuell zum Flashen des PBL gebraucht werden und dafuer anstelle der "Application" geladen werden. > Im Dump kann ich Deine Start-Adressen nicht nachvollziehen, oder war > das nur eine Idee wie es sein könnte? Das ist eigentlich ziemlich offensichtlich, in jedem der drei Bloecke steht das ja sogar als String: Offset 0x2000: IBL V 1.210 23-07-08 RX-42 HW60 (c) NOKIA. Offset 0x12000: PBL V 1.210 23-07-08 RX-42 HW60 (c) NOKIA. Offset 0x82000: V 1.210 23-07-08 RX-42 HW60 (c) NOKIA. Ich wuerde mir aber dennoch zuerst den seriellen EEPROM ansehen, der wird bereits im IBL verwendet. Das sollte beim funktionierenden Geraet auch ohne Ausloeten mit dem Logic-Analyzer machbar sein, die 8 KByte muessten eigentlich an einem Stueck beim Start gelesen werden.
Angehängte Dateien:
-
bt-module_parts_top.jpg
420 KB -
M29W800DB_memory-map_boot-block.jpg
44 KB -
m29w160et_memory-map.jpg
95 KB
So, habe mal alle relevanten Bauteile identifiziert und markiert.
In Bezug auf Deine Frage Dieter: Ich habe kein EEPROM gefunden.
Jedoch etwas interessantes über den Flash-Chip (2). Der hat sowas wie
einen Boot- und zwei Datensektoren. Die liegen beim "*ET" im oberen
Adressbereich des Chips und der ist im Dump leer. Daher vermute ich das
er nicht genutzt wird, da der CP3CN37 wohl ab Adresse 0x0000 0000 vom
Flash bootet (so meine Theorie).
==== (1) Zentralprozessor (BT/USB/CAN) ====
* Function: Bluetooth, USB, CAN, CR16C RISC CPU, Internal
SRAM/Flash/Boot-ROM
* Marking: NS CP3CN37VVAWQ (CP3CN37-Serie)
* Package: LQFP-144
==== (2) M29W160ET ====
Angeschlossen als externer Flash-Speicher des CP3CN37 (Flash 3).
* Function: 16 Mbit (2 Mbyte), 3V Parallel NOR Flash Memory
* Marking: ST M29W160ET
* Package: TSOP-48
* Features:
* 1 boot, 3 parameter and 31 main blocks
* "*ET" = Top Boot Block Device = Bootblock Address 0x001F C000 -
0x001F FFFF
* Manufactorer code: 0x0020
* Chip-ID 0x22C4 (ET)
==== (3) FMP1617CA5 ====
* Function: External RAM of CP3CN37
* Marking: FIDELIX FMP1617CA5
* Package: BGA
==== (4) TMS320VC5507 ====
* Function: Digitaler Signalprozessor (DSP)
* Marking: TMS320 VC5507ZHH
* Package: QFP
==== (5) M29W640GL ====
* Function: Flash-Speicher 1
* Marking: ST M29W640GL
* Package: TSOP-56
==== (6) K4S641632N ====
* Function: DSP RAM
* Marking: Samsung K4S641632N
* Package: TSOP
==== (7) M29W800DB ====
* Function: 8-Mbit (1 Mbit x 8 or 512 Kbits x 16, boot block) 3V
supply flash memory
* Marking: ST M29W800DB
* Package: TSOP48
* Features:
* 19 memory blocks = 1 boot block (top or bottom location), 2
parameter and 16 main blocks
* Common flash interface, 64-bit security code
* "*DB" = "bottom boot" location. The 16-Kbyte boot block (0x00000
to 0x03FFF) can be used for small initialization code to start the
microprocessor, the two 8-Kbyte parameter blocks (0x04000 - 0x05FFF and
0x06000 - 0x07FFF) can be used for parameter storage and the remaining
32-Kbyte is a small main block where the application may be stored.
==== (9) TLV320AIC33 ====
* Function: Low-Power Stereo CODEC with 10 Inputs, 7 Outputs,
HP/Speaker Amplifier and Enhanced Digital Effects
* Marking: AIC331 TI 18W
* Package:
==== (10) BV417 ====
* Function: Bluetooth Chipset
* Marking: csr BC417 143BGQ
* Package: BGA
==== (11) SN65LBC179D ====
* Function: LOW-POWER DIFFERENTIAL LINE DRIVER AND RECEIVER PAIRS
* Marking: TI 6LB179 19M AELR
* Package: SO8
==== (12) SN74LVTH374 ====
* Function: 3.3V ABT OCTAL EDGE-TRIGGERED D-TYPE FLIP-FLOPS WITH
3-STATE OUTPUTS
* Marking: LXH374
* Package: SO20
==== (13) ? ====
* Function:
* Marking: C57 162
* Package: SO8
==== (14), (15) ST TS922 ====
* Function: Dual Power OpAmp
* Marking: 9221 ST EB132
* Package: SO8
==== (16) L2902 ====
* Function: 4-Fach OpAmp
* Marking: TI L2902
* Package: SO14
==== (17) TJA1041 ====
* Function: High speed CAN transceiver
* Marking: NXP TJA1041
* Package: SO14
==== (18) LP2951 ====
* Function: Series of Adjustable Micropower Voltage Regulators
* Marking: NS MFAR 2951
* Package: SO8
==== (19) ? ====
* Function:
* Marking: BBW 19W Z46T (oder auf anderem Modul "BBW 86W Z267")
* Package:
==== (20), (21) LM2734 ====
* Function: 1A Load Step-Down DC-DC Regulator
* Marking: M16AB L163B
* Package: TSOT-6 (Thin SOT23)
==== (22) ? ====
* Function:
* Marking: BUH TI K 62F3 (nicht gut lesbar)
* Package:
==== (23) ? ====
* Function:
* Marking: 564R B134
* Package:
==== (24) ? ====
* Function:
* Marking: 591AF
* Package: SOT-6
==== ? ====
* Function:
* Marking: 2313 11GDS
* Package: SO8
==== ? ====
* Function:
* Marking: ASYAB
* Package: SO6
:
Bearbeitet durch User
Olli Z. schrieb: > In Bezug auf Deine Frage Dieter: Ich habe kein EEPROM gefunden. Der EEPROM muesste am Microwire Interface (MSK, MDIDO, MDODI) angeschlossen sein. Vielleicht laesst sich das einfach auf der Platine verfolgen. Ich wuerde auf einen der Chips im SO8 Gehaeuse tippen.
Dieter schrieb: > Der EEPROM muesste am Microwire Interface (MSK, MDIDO, MDODI) > angeschlossen sein. Vielleicht laesst sich das einfach auf der Platine > verfolgen. Ich wuerde auf einen der Chips im SO8 Gehaeuse tippen. Ich prüf das gern nochmal, aber die hatte ich mir natürlich auch als erstes zur Brust genommen ;-) aber keiner davon war ein EEPROM (siehe meine Liste oben).
Ich geben dem EEPROM so hohe Prioritaet weil der in der ganzen Kette IBL -> PBL -> Application eine wichtige Rolle spielt. Der Inhalt wird auf Integritaet geprueft und steuert ausserdem ob und wie die Bootreihenfolge ausgefuehrt wird. Sollte also mit dem EEPROM etwas nicht stimmen (z.B. defekt oder Inhalt ist nicht in Ordnung) koennte es passieren dass die MCU im IBL oder PBL bleibt, dann haette man den Effekt den Du beim defekten Geraet beobachtest. Du koenntest Dich beim funktionierenden Geraet auch mit dem Logic-Analyzer an die Microwire Signale haengen, das sollten ca. 5 MHz Takt sein und beim Einschalten werden die 8 KByte gelesen.
Ich werde das messen und berichten! :] Ich chekc immer noch nicht wie das mit dem Bootmode laufen soll. Der wird ja über die ENV-Pins bestimmt. Wären die umbeschaltet würden die internen Pullups für 11 sorgen, was einem Booten von der externen Adresse 0x40 0000 zur Folge hätte. Ich sehe da aber Bauteile an den Pins und kurz nach dem anlegen der Spannung erscheint dort ein Takt. Die Pins haben ja auch einen PLL Ausgang als Funktion, also glaube ich das dies kurz nach dem Start umprogrammiert wird. Wenn dem so ist, dann bootet das Teil eben nicht mit dem internen ROM sondern direkt vom Flash. Somit müsste zu Beginn des Dumps lauffähiger Maschinencode stehen und dies der initiale Bootloader sein.
Olli Z. schrieb: > Somit müsste zu Beginn des Dumps lauffähiger Maschinencode stehen und dies der initiale Bootloader sein. Da steht ja auch lauffaehiger Maschinencode, das hatte ich schon beschrieben: Offset Image 0x000000 (Addresse 0x400000) IBL (Initial Boot Loader?) Offset Image 0x010000 (Addresse 0x410000) PBL (Primary Boot Loader?) Offset Image 0x080000 (Addresse 0x480000) Application Das sind auch direkt die Startadressen fuer IBL, PBL und Application. Aber der EEPROM bestimmt den Ablauf und kann bewirken dass die "Application" nie erreicht wird.
Angehängte Dateien:
Olli Z. schrieb: > Dieter schrieb: >> Der EEPROM muesste am Microwire Interface (MSK, MDIDO, MDODI) >> angeschlossen sein. Vielleicht laesst sich das einfach auf der Platine >> verfolgen. Ich wuerde auf einen der Chips im SO8 Gehaeuse tippen. Habe das gestern mal ausgemessen. Mir scheint als wären nur MSK und MDODI verbunden. Dort konnte ich jedenfalls mit dem Oszi "aktivität" feststellen. MDIDO hingehen blieb ruhig. Die beiden Signale verlaufen vom CP3CN37 über je einen 33 Ohm Widerstand zum Bauteil (23), einem 8-poligen SO8 irgendwas. Das Teil ist beschriftet mit "564R / B047", mehr ist nicht zu erkennen. Habe dazu nichts im Netz finden können. Jedenfalls habe ich meinen LA mal an beide Pins vom funktionierenden Modul angeschlossen und das Ergebniss als ZIP beigefügt. Nach 8kb schaut das wahrlich nicht aus.
:
Bearbeitet durch User
Olli Z. schrieb: > Das Teil ist beschriftet mit "564R / B047", > mehr ist nicht zu erkennen. Zu "564" gaebe es z.B. den GT25C64, das ist ein serielles EEPROM mit 8 KByte. Koenntest Du eventuell das Ergebnis vom Logic-Analyzer als CSV oder Text Datei exportieren? Danke.
Olli Z. schrieb: > Jedenfalls habe ich meinen LA mal an beide Pins vom funktionierenden > Modul angeschlossen und das Ergebniss als ZIP beigefügt. Nach 8kb schaut > das wahrlich nicht aus. Der Trace machen schon Sinn, es fehlen allerdings noch die Daten vom EEPROM zur MCU. Man sieht in dem Trace dass zuerst 0x05 ("Read Status Register") zum EEPROM geschickt wird, danach 0x03 ("Read Data from Array").
Angehängte Dateien:
-
564_la.jpg
46 KB -
cp3cn37_microwire_spi.jpg
49 KB
Dieter schrieb: > Olli Z. schrieb: >> Das Teil ist beschriftet mit "564R / B047", >> mehr ist nicht zu erkennen. > Zu "564" gaebe es z.B. den GT25C64, das ist ein serielles EEPROM mit 8 > KByte. Du bist klasse! Ja, das könnte in der Tat stimmen! Wie bist Du da drauf gekommen? Ich habe natürlich auch nach Kombinationen von 564, 564R und EEPROM gesucht, aber nichts gefunden... Zumindest das Gehäuse ist nun bekannt, es handelt sich um ein "UDFN" Package, dabei liegen die Pins am Rand unter dem Chip. Mit etwas Glück finde ich Durchkontaktierungen oder andere Punke an denen ich die Signal abgreifen und zu einem Programmer zwecks auslesen führen kann. Zur not löte ich das Ding aus, das dürfte noch recht einfach gehen mit Heißluft. Fürs auslesen müsste ich mir dann ne kleine Platine basteln. Was mich wundert (stört) ist das scheinbar nur MSK (Clock) und MDIDO an den Chip gehen sollen. Das kann eigentlich nicht sein, denn so würde das EEPROM ja nur gelesen werden können (MDIDO führt vom Slave, dem EEPROM zum Master, der MCU) und die Software gar keine SPI-Kommandos schicken kann, denn dazu bräuchte sie das MDODI Signal... Auch vermisste ich ein /MWCS um den Chip überhaupt anzusprechen. Das muss ich alles nochmal nachmessen am vermeintlichen EEPROM. > Koenntest Du eventuell das Ergebnis vom Logic-Analyzer als CSV oder Text > Datei exportieren? Danke. Gern, aber leider spuckt der Salaelogic maximal CSV raus, welche man erstmal noch in BIN konvertieren müsste um einen Datenstrom zu erhalten. Weiterhin bin ich mir unsicher ob mein Analyze auch stimmt. Auf dem Screenshot examplarisch gezeigt sieht man gut die Clocks (MSK), aber die Linie darüber sieht mir fast garnicht nach einem Datensignal aus, sondern eher nach einem Chipselect?
Dieter schrieb: > Der Trace machen schon Sinn, es fehlen allerdings noch die Daten vom > EEPROM zur MCU. Man sieht in dem Trace dass zuerst 0x05 ("Read Status > Register") zum EEPROM geschickt wird, danach 0x03 ("Read Data from > Array"). Das würde meinen Verdacht bestätigen das ich nur das DO von der MCU erwischt hab, nicht aber das DI. Ich schau mir das heute Abend nochmal ganz genau an. Ich denke es wird sinnvoll sein den Chip separat auszulesen.
Olli Z. schrieb: > Ich habe natürlich auch nach Kombinationen von 564, 564R und > EEPROM gesucht, aber nichts gefunden... "EEPROM" "564" (mit den Anfuehrungszeichen) liefert bei Google als zweites Ergebnis den GT25C64. Der zweite Teil des Logic-Analyzer Trace ist das Beschreiben von 512 Bytes ab EEPROM Adresse 0x0C00, in diesem Fall sind die Daten ja im Trace enthalten. Das Ganze passiert in Bloecken zu je 32 Bytes, danach wird jeweils der Status Register gelesen, vermutlich um darauf zu warten dass das Schreiben der 32 Bytes abgeschlossen ist. Jetzt fehlen also nur noch die Daten vom EEPROM zur MCU. Und im Vergleich dazu die EEPROM Daten des defekten Steuergeraets.
Dieter schrieb: > Der Trace machen schon Sinn, es fehlen allerdings noch die Daten vom > EEPROM zur MCU. Man sieht in dem Trace dass zuerst 0x05 ("Read Status > Register") zum EEPROM geschickt wird, danach 0x03 ("Read Data from > Array"). Stimmt, wenn man den SPI-Analyzer richtig einstellt bekomme ich auch andere Daten angezeigt. Da hatte ich etwas falsche Paramter bezüglich des Ruhepegels und Data-Valid-Flanke vom MSK (Clock). Dann habe ich in der Data-Line also den Kanal von der MCU zum EEPROM geloggt. Relevant wäre ja auch noch der Rückweg um zu sehen was aus dem EEPROM raus kommt. Im Sendekanal sieht man dabei ja nur Dummy-Bytes (0x00) weil ein lesen im SPI immer auch ein schreiben ist, klar. Wenn Du Dir den Signalverlauf ansiehst kommt das aber irgendwann später "aus dem Takt", da werden dann offensichtlich Bits eines Datenwortes in das nachfolgende verlagert.
Angehängte Dateien:
-
eeprom_spi_cmds.jpg
81 KB
Habe heute mal die EEPROM pins "durchgepiepst". Zum einen musste ich feststellen das mein defektes und mein intaktes Laufwerk nicht den gleichen Boardaufbau haben. Die Modellnummer von Ford ist nahezu gleich, aber das eine ist von Nokia und das andere von Novero. Die Software ist beide diesselbe, aber das PCB-Layout ist an wenigen Stellen geringfügig anders. Wie auch immer, ich hab die Pins am intakten Modul gefunden und festgestellt das es wie folgt verbunden ist (links EEPROM, rechts CP3CN37):
1 | /CS (1) --> geht über 100 Ohm (und C nach Vcc) auf 6Q (15) vom 74374, 6D davon auf XD5 (43) vom CP3CN37 |
2 | SO (2) --> MDIDO (94) |
3 | /WP (3) über Kondensator auf Vcc gezogen |
4 | SI (5) --> MDODI (93) |
5 | SCK (6) --> MSK (95) |
6 | /HOLD (7) über Kondensator auf Vcc gezogen |
Am SPI-Port hängen definitiv weitere Teilnehmer. Daher war es notwendig auch ds /CS-Signal auf den LA zu führen. Das /CS wird nicht direkt vom CP3CN37 erzeugt sondern kommt von einem Logikgatter (Flipflop) welches aus den Datenleitungen des CP3CN37 gespeist wird. Hier multiplexed man also um mit einem SPI-Port mehrere Geräte ansprechend zu können. Interessant, scheinbar vertraut man dem Master/Slave des Bus nicht, denn das ginge ja auch alles ganz ohne diese Fisematenten... Nun habe ich einen LA-Log angefügt welcher alle Signale des EEPROM enthält. Der EEPROM kennt ja nur wenige SPI-Befehle:
1 | 0000 0001 (0x01) = Write status register |
2 | 0000 0010 (0x02) = Write data to array |
3 | 0000 0011 (0x03) = Read data from array |
4 | 0000 0100 (0x04) = Reset write enable latch |
5 | 0000 0101 (0x05) = Read status register |
6 | 0000 0110 (0x06) = Set write enable latch |
Im ersten Block wird der EEPROM ausgelesen:
CP3CN EEPROM
0x05 -->
<-- 0x00
= Read status register (= 0x00)
0x03 -->
0x00 -->
0x00 -->
= Read data from array, start at 0x0000 0000
<-- 02 00 C4 22 FF FF ...
Später dann, im zweiten block wird der EEPROM beschrieben.
:
Bearbeitet durch User
Der EEPROM Inhalt schaut schluessig aus, jetzt waere im Vergleich dazu der Inhalt des EEPROM aus dem defekten Geraet interessant. Die Testpads in der Naehe des EEPROM schauen interessant aus, vielleicht kann man ja darueber auf den EEPROM zugreifen, dann braucht man ihn nicht ausloeten. Olli Z. schrieb: > Später dann, im zweiten block wird der EEPROM beschrieben. Das war auch schon im ersten Trace zu sehen (siehe mein Kommentar weiter oben).
Leider scheint es keine Testpoints zu geben, hab quasi alles durchgepiepst. Man muss teils an anderen Bauteilen anlöten. Aber das allein wär noch nicht das Problem. Ich habe ja die drei Flashs vom defekten Modul runtergelötet um zu prüfen ob was drin steckt und ob man da Fehler erkennt, ggf. neu programmiert. Die müssen wohl erst wieder drauf sonst geht da sicher garnichts. Das würde ich aber eigentlich nur machen wollen wenn klar ist das ich sie nicht wieder runterlöten muss, denn das wär sicher nur mit defekten Pads verbunden :-/ Daher würde ich mal versuchen für den UDFN Chip, welchen ich vom defekten Modul runtergelötet hab, einen Adapter für meinen RT809H Programmer zu basteln und den damit auslesen. Da die Module nicht 100% gleich sind, erwarte ich eigentlich nicht das die Daten darin es sind. Es ist auch die Frage WAS das für Daten sind.
Olli Z. schrieb: > Ich habe ja die drei Flashs vom > defekten Modul runtergelötet um zu prüfen ob was drin steckt und ob man > da Fehler erkennt, ggf. neu programmiert. Die müssen wohl erst wieder > drauf sonst geht da sicher garnichts. Wenn die MCU nichts machen kann wegen des fehlenden Flash bzw. im Reset gehalten wird dann kann man vermutlich den EEPROM auch ohne Ausloeten auslesen, die IOs der MCU sind dann vermutlich nicht aktiv. Olli Z. schrieb: > Es ist auch die Frage WAS das für Daten sind. Das habe ich ja schon erwaehnt, damit wird u.a. festgelegt wie und ob der Ablauf IBL -> PBL -> Application stattfindet. Und genau dieser Bereich ist interessant fuer den beobachteten Fehler. Der Rest im EEPROM, (Fehlerspeicher, Seriennummer usw.) ist weniger relevant.
Ich bastle grad nen Adapter, da ich ihn eh schon ausgelötet hab. Aber sag mal, woher weißt Du denn was da alles wo drin steht? Ich finde in den Daten (hab mir mal schnell mit PHP nen Umsetzer von CSV zu BIN gemacht) weder eine Seriennummer, noch eine Typenbezeichnung, noch sonst irgendwelche menschenlesbaren Texte. Der Rest ist für mich bislang nur Digitalmüll ;-)
Olli Z. schrieb: > Aber sag mal, woher weißt Du denn was da alles wo drin steht? Jetzt sind wir wieder am Anfang, bei meinem ersten Beitrag hier. Reinschauen ins Binary mit einem Disassembler hilft weiter.
Olli Z. schrieb: > Ich finde in den Daten (hab mir mal schnell mit PHP nen Umsetzer von CSV > zu BIN gemacht) weder eine Seriennummer, noch eine Typenbezeichnung, > noch sonst irgendwelche menschenlesbaren Texte. Dann stimmt etwas nicht mit Deiner Umwandlung, der EEPROM Inhalt ist in der angehängten Datei.
Angehängte Dateien:
Ich war mal ganz forsch und habe nur das Flash für den CP3CN37 wieder eingelötet und natürlich das EEPROM. Dann die Abgriffe drangelötet und einen Scan gemacht. Datei mit logicdata und CSV-Export liegt im ZIP. Auf dem LA-Bild kann man schön erkennen das er anscheinend ständig versucht das EEPROM zu lesen, unaufhörlich. Als würde da irgendwann was anderes rauskommen ;-)) Somit hast Du, Dieter absolut Recht das er mit dem Inhalt des EEPROM irgendwie unzufrieden ist. Bin mal gespannt ob Dir daran was auffällt. Zur Konvertierung: Mir ist es bislang nicht gelungen aus dem CSV-Export ein vernünftiges BIN-File zu erzeugen. Das TXT-File sieht so aus:
1 | Time [s],Packet ID,MOSI,MISO |
2 | 0.424679458333333,0,0x05,0xFF |
3 | 0.424685666666667,0,0x00,0x00 |
4 | 0.424699708333333,1,0x03,0xFF |
5 | 0.424703083333333,1,0x00,0xFF |
6 | 0.424706458333333,1,0x00,0xFF |
7 | 0.424713041666667,1,0x00,0x20 |
8 | 0.424715500000000,1,0x00,0x00 |
9 | 0.424717916666667,1,0x00,0xC4 |
10 | 0.424720375000000,1,0x00,0x22 |
11 | ... |
12 | 0.444736958333333,1,0x00,0x6A |
13 | 0.444739416666667,1,0x00,0xCD |
14 | 0.444741833333333,1,0x00,0xAB |
15 | 0.633914625000000,2,0x05,0xFF |
16 | 0.633920250000000,2,0x00,0x00 |
17 | 0.633944916666667,3,0x06,0xFF |
18 | 0.633955416666667,4,0x05,0xFF |
19 | 0.633958958333333,4,0x00,0x02 |
20 | 0.633969583333333,5,0x02,0xFF |
21 | 0.633973000000000,5,0x1C,0xFF |
Die "ID" wird die jeweilige Session sein, also Datenempfang und Reaktion darauf, gemäß dem oben gezeigten Operator-Plan. Im Fall der Binärdaten nehme ich also ID1 und zwar das rechte Byte (MISO). Da der Operator 0x03 (Read from array) drei Byte lang ist, ziehe ich diese einfach ab. Der Rest, bis zur nächsten ID sollte dann der EEPROM-Inhalt sein. Ich versteht auch eigentlich nicht, warum der LA keinen Binär-Export hat. Aber gut... an dem Tool wär noch so einiges zu verbessern. Aber für Lau ist das natürlich trotzdem gut. Hab mein Programm abgeändert und nun spuckt es auch die richtige Binärdatei aus. Die vom defekten Modul habe ich gleich mal angehanden. Im Vergleich zum Intakten ist darin wirklich einiges schräg! Kein Wunder das der Boot fehl schlägt. Aber wie komme ich nun an den richtigen Inhalt und wie programmiere ich den drauf? Ich müsste die CPU im RESET halten, damit die mir nicht dazwischenfunkt. Aber auch die anderen Chips nicht die an diesem SPI hängen.
:
Bearbeitet durch User
Olli Z. schrieb: > Somit hast Du, Dieter absolut Recht das er mit dem Inhalt des EEPROM > irgendwie unzufrieden ist. Bin mal gespannt ob Dir daran was auffällt. Wie Du ja schon selber festgestellt hast ist der EEPROM Inhalt vom defekten Gerät so ziemlich hinüber. Dadurch springt der IBL nicht mehr in den PBL, dafür wird ein Reset ausgeführt und es geht von Neuem los. Das erklärt warum sich das Lesen des EEPROM dauernd wiederholt. Leider ist von den Original-Daten nichts mehr zu sehen (z.B. Seriennummer). Du könntest die Daten vom funktionierenden Gerät in den EEPROM schreiben und schauen ob das funktioniert. Die Frage ist ob man z.B. die Fahrgestellnummer (steht auch im EEPROM) anpassen muss, das erfordert aber noch mehr (Block-CRC aufgrund der die Änderung korrigieren). Ich würde die MCU zum Schreiben im Reset halten, das sollte gehen.
Nur mal als Zwischenstand: Wenn ich den RESET-Pin der CPU auf GND halt scheint da wirklich Funkstille zu sein auf dem SPI-"Bus" (ist je gemultiplexed). Ich kann auch den EEPROM auslesen und erkenne den fehlerhaften Inhalt, also scheint das zu klappen. Da mein Programmer, der RT809h genau diesen EEPROM Typ nicht kennt, meckert er natürlich über die Chip-ID, aber das ist wohl egal. Dann habe ich versucht den EEPROM zu löschen, das schlug mehrfach fehl, an diversen Stellen. Nach gefühlt 10mal wipe war er dann tatsächlich leer... hmmm. Beschreiben lies er sich nur zum Teil. Könnte schon sein das das Ding hin ist. Habe dann nach einem Erase mal versucht den Chip komplett mit 0x00 zu füllen. Das Ergebnis habe ich mal hochgeladen. Die ersten Bytes bis 0x00FF sind immer 0xFF, egal was man macht. Der Bereich 0x0800 - 0x09FF lässt sich auch nicht wirklich überschreiben. Interessanterweise nahm er aber nach zig Löschversuchen wenigstens den Wert 0xFF an. Offenbar können sich manche Bits nicht mehr auf 0 stellen. Jetzt wollte ich den vom intakten Modul nicht irgendwie zerfrickeln, daher überlege ich irgendeinen 64kbit SPI-EEPROM dort einzulöten. Per Prinzip sollte das doch fast egal sein. Wenn ich mir z.B. einen FM25C64 anschaue ist der sowohl Pin- als auch Protokollkompatibel. Ein GT25C64 ist als UFDN am Markt nicht zu finden, selbst in China nicht...
Dieter schrieb: > Olli Z. schrieb: >> Aber sag mal, woher weißt Du denn was da alles wo drin steht? > > Jetzt sind wir wieder am Anfang, bei meinem ersten Beitrag hier. > Reinschauen ins Binary mit einem Disassembler hilft weiter. Würde ich gern mal tun, auch wenn Du davon ganz klar mehr verstehst als ich. Dazu bräuchte ich aber wenigstens dieses Plugin, fertig kompiliert. Kannst Du mir das nicht per Mail senden? Einen alternativen CR16C disassembler konnte ich nicht finden. disassembler.io kann es scheinbar nicht.
Olli Z. schrieb: > Wenn ich mir z.B. einen FM25C64 > anschaue ist der sowohl Pin- als auch Protokollkompatibel. Ein anderer EEPROM ist vermutlich kein Problem wenn die Kommandos identisch sind und die Page-Size beim Schreiben passt. Er sollte aber auch die ca. 5 MHz Takt können, manche Alternativen sind langsamer.
Dieter schrieb: > Ein anderer EEPROM ist vermutlich kein Problem wenn die Kommandos > identisch sind und die Page-Size beim Schreiben passt. Die meisten die ich mir so angesehen hab arbeiten exakt so wie der GT. Gleiche Befehle, gleiche SPI-Modes. Ob die Pagesize wirklich relevant ist? Wir sehen doch im Trace das die MPU einfach alle Daten anfordert und beim schreiben alle Daten in einem Rutsch speichert. > Er sollte aber auch die ca. 5 MHz Takt können, manche Alternativen sind langsamer. Da hast Du recht, klar. Aber was ich so gesehen hab schaffen die meisten locker 20 Mhz. Jedenfalls habe ich gestern den GT25C64 vom intakten board runtergelötet und über die Anschlüsse, welche ich mir fürs Debugging am Board angelötet hatte dazu benutzt einen externen ZIF-Sockel anzuschließen. Hier hinein habe ich dann einen ST M95640 gesteckt, welchen ich zuvor mit dem Inhalt vom Intakten EEPROM programmiert hatte. Und siehe da, das intakte Board läuft auch damit! Somit ist klar das auch alternative EEPROMs hier taugen :-) Dann habe ich diesen EEPROM in gleicher Weise am defekten Board angeschlossen, aber da tat sich nichts weiter ;-( Den LA Scan füge ich gleich noch bei, muss noch die Daten extrahieren, aber ich habe erkannt das der Inhalt schon geliefert wird, die MPU diesen aber immer wieder anfordert. Also gleiches Spiel wie beim defekten EEPROM. Offenbar ist der Algo nicht zufrieden mit dem was er liest, sprich es passt nich zur Firmware im Flash. Die Dateien hab ich angefügt. Interessanterweise unterscheidet sich der Inhalt der vom EEPROM im Scanlog geliefert wird von dem ursprünglich einprogrammierten. Es sind nicht viele Differenzen, aber es sind welche. Offenbar würde der Inhalt verändert, nachdem ich das EEPROM programmiert und eingesetzt hatte. Das muss ich mir nochmal anschauen, nicht das es daran liegt das der Inhalt von der MPU nicht akteptiert wird.
:
Bearbeitet durch User
Olli Z. schrieb: > Offenbar würde der Inhalt verändert, nachdem ich das EEPROM programmiert > und eingesetzt hatte. Es gibt z.B. einen Start-Zähler, das sollte aber nicht stören wenn der hochgezählt wird. Mein Verdacht: Du hast wohl beim defekten Board bisher nur den Flash der MCU wieder eingelötet. Eventuell macht es ja Probleme wenn DSP bzw. Bluetooth nicht funktionieren (wegen des noch fehlenden Flash). Vielleicht einfach mal die beiden Flash Bausteine auch wieder einlöten, nur um sicher zu sein dass das ganze Board funktionsfähig ist.
In der angehängten EEPROM Datei sind die wichtigsten Dinge für das alte Gerät angepasst. Hintergrund: die 8 KByte des EEPROM sind in 512 Byte Blöcke aufgeteilt, die mit einer 16-Bit CRC gesichert sind (aber nur wenn am Ende des Blocks der Marker 0xABCD steht). Die CRC geht nur über den tatsächlich belegten Bereich, an dieser Stelle gibt es ein paar Unterschiede zwischen dem defekten und funktionierenden Gerät. Idealerweise versuchst Du es wenn alle Flash-Bausteine wieder eingelötet sind um auszuschließen dass es dadurch Probleme gibt.
Dieter schrieb: > Es gibt z.B. einen Start-Zähler, das sollte aber nicht stören wenn der > hochgezählt wird. Ja, könnte gut sein. Muss ich mal mehrere Startversuche machen und nachsehen. Ist zumindest interessant. > Mein Verdacht: Du hast wohl beim defekten Board bisher nur den Flash der > MCU wieder eingelötet. Stimmt! Dann werde ich die mal wieder einsetzen und nochmal schauen..
Leider, leider, auch nach wiedereinlöten der beiden anderen Flash-Chips kein Unterschied. Weder mit dem EEPROM Inhalt vom funktionierenden Modul, noch mit dem von Dir korrigierten. Ich habe den Inhalt des EEPROMs nach mehreren Startversuchen immer wieder zurückgelesen, konnte aber keine Änderung des Inhaltes feststellen. Ich fürchte da hab ich etwas falsch interpretiert oder der LA-Scan war irgendwie "wackelig". Der Inhalt im EEPROM bleibt unverändert. Ich denke fast das die anderen Modulteile erst gestartet werden, wenn die vom EEPROM gelieferten Daten für die im CP3-Flash laufende Software ok ist. Im RESET zieht das Modul bei 12V 50mA. Im Betrieb ohne EEPROM 60mA und mit EEPROM (aber ständigem Reread-Loop) 70mA. Wenn es hochfährt (also beim intakten Modul) sind es 115mA. Also, klar ist das die Daten eigentlich nur einmal vom CP3 gezogen würden, würde er diese akzeptieren. Es muss also irgendwas darin sein womit er nicht klar kommt, oder was nicht passt. Dazu müsste man wohl die Routine, welche nach dem lesen läuft, debuggen. Womöglich nur ein CRC-Fehler?! Ich suche schon eine ganze Weile nach einem gleichen Modul, aber wie es der Teufel will ist ausgerechnet das Nokia 8M5T-19C112-BK nicht zu finden, nur *-BM oder andere. Gut möglich das elektronisch nun alle ok ist, aber wir einfach die falschen Daten haben. Mein funktionierendes Modul ist ein novero 8M5T-19C112-BT (Typ RX-42, HW: 0703, Serial 338684091, 0567420, S46 0703) Das defekte ein NOKIA 8M5T-19C112-BK (Typ RX-42, HW: 0600, Serial C5A142457, 0542387, 0515063/20/086874 P49 0600)
:
Bearbeitet durch User
Olli Z. schrieb: > Leider, leider, auch nach wiedereinlöten der beiden anderen Flash-Chips > kein Unterschied. Weder mit dem EEPROM Inhalt vom funktionierenden > Modul, noch mit dem von Dir korrigierten. Was mich wundert ist dass nur vom EEPROM gelesen wird und dann das Ganze von vorne losgeht. In der Firmware wird bei jedem Fehler ein Eintrag in den Fehlerspeicher im EEPROM geschrieben, das passiert aber nicht. Wenn man wüsste wo der Neustart erfolgt könnte man das Problem lösen, aber ohne den Eintrag im Fehlerspeicher wird es schwierig. Man könnte es auch mal mit einem leeren EEPROM probieren (alles 0xFF), eigentlich sollten bei leerem EEPROM in mache Blöcke Default-Werte eingetragen werden.
Habs probiert, wird nichts eingetragen. Komisch, ich probier dasselbe nochmal mit dem funktionierenden Modul... P.S.: Habe mal etliche CRC-16 Algos durchprobiert, konnte aber mit keinem eine Prüfsumme nachberechnen.
:
Bearbeitet durch User
Ah, interessant! Ich habe das gelöschte EEPROM am funktionierenden Modul eingesetzt und dieses gestartet. Es ging erst auf 65mA und kurz darauf hoch auf 115mA. Danach habe ich den Inhalt vom EEPROM zurückgelesen (ist beigefügt) und da stehen tatsächlich dann Inhalte drin. Offenbar ist der tatsächliche Inhalt des EEPROM somit völlig egal?! Vielleicht nur dann nicht, wenn Mist drin steht... Aber diese Initialisierung macht das defekte Modul definitiv nicht.
Olli Z. schrieb: > Aber diese Initialisierung macht das defekte Modul definitiv nicht. Das ist seltsam, diese Default-Werte werden schon vom IBL geschrieben wenn nichts sinnvolles im EEPROM steht. Der IBL greift nach meinem bisherigen Verständnis auch noch nicht auf andere Hardware zu, d.h. wenn die MCU funktioniert sollte dieser Ablauf stattfinden. Bisher sah es ja so aus als ob nur der EEPROM defekt ist, das wäre auch ein schlüssiger Fehler. Nur als Idee: Falls es einen Watchdog gibt (intern oder extern als separater Chip) könnte eventuell ein Reset ausgelöst werden bevor die MCU weitermachen kann. Allerdings erklärt das nicht warum es bei dem funktionierenden Gerät nicht so abläuft.
In den Logicdatas die ich oben angefügt hab kann man ja gut erkennen das er praktisch sofort nach Ende eines Lesezykluses wieder in den nächsten geht. Muss mal das Datenblatt lesen ob man einen internen Reset aussen an den Pins irgendwo/irgendwie erkennt. Das eine Flash vom defekten Modul war ja definitiv molo. Der Inhalt war Kraut und Rüben, es liest sich nicht wirklich löschen und beschreiben, hatte teilweise RO-Ähnliche Bereiche. Mit meinem M95640 funktioniert ja das intakte Modul auch ohne EEPROM-Inhalt. Ich muss nochmal testen was passiert wenn ich Quatsch da rein schreibe! Unter Umständen macht es diese Grundinitialisierung nur, wenn der Inhalt leer ist. Aber das hilft uns auch nicht weiter... ist nur interessant zu wissen. Irgendwas passiert jedenfalls nachdem der Inhalt in das RAM der MCU geladen wurde und das könnte man ggf. nur mittels JTAG-Debugging herausfinden, wo wir wieder am Anfang meiner Beiträge wären. Leider scheint es keinen Debugger zu geben der CR16C beherrscht.
Auch interessant. Wenn ich das EEPROM per RANDOM-FILL vollmache und im intakten Modul starte, läuft dieses auch hoch. Der nachträgliche Readout ist angehangen und man sieht das nur einige Teile initialisiert werden. Leider hatte ich vergessen VORHER den Random-Fill abzuspeichern, dann könnte man sogar isolieren was neu geschrieben wird und was erhalten bleibt.
:
Bearbeitet durch User
Ich verstehe noch nicht warum beim defekten Gerät ein leerer EEPROM nicht auch mit Default-Werten initialisiert wird. Es wird im IBL zwar der Watchdog gestartet, der sollte aber erst nach einigen Sekunden einen Reset auslösen und so lange dauert es ja nicht bis das EEPROM Lesen wieder von vorne los geht. Interessant wäre zum vergleichen der IBL aus dem funktionierenden Gerät, der ist ja leider nicht in der USB Firmware-Update Datei enthalten. Nur macht es vermutlich wenig Sinn auch beim funktionierenden Gerät den Flash auszulöten solange nicht sicher ist dass man damit auch wirklich neue Erkenntnisse über die Abläufe gewinnt.
Eventuell doch ein HW-Defekt? Es wäre z.B. denkbar, dass an der MCU der MISO Input defekt ist und das Signal auf der Leitung intern nicht weiterverarbeitet werden kann. Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > Eventuell doch ein HW-Defekt? > > Es wäre z.B. denkbar, dass an der MCU der MISO Input defekt ist und das > Signal auf der Leitung intern nicht weiterverarbeitet werden kann. Ausschließen kann man das nicht, wobei ich aber dennoch erwarten würde dass versucht wird die mit Default-Werte korrigierten EEPROM Daten zurückzuschreiben wenn nichts sinnvolles gelesen wurde. Das kann ich im Logic-Analyzer Trace nicht finden. Eine weitere Idee: Ich sehe dass im IBL an diversen Stellen Bit 5 vom Port-E (PE5 an Pin 3 der MCU) kurz auf "0" und dann wieder auf "1" gesetzt wird. Ob das eventuell einen externen Supervisor-Chip triggert? Es gibt ja noch ein paar nicht identifizierte, kleinere Chips, vielleicht ist da ja einer dabei. Wenn das Triggern nicht mehr klappt (eventuell ist bei den inzwischen doch recht vielen Aus- und Einlötaktionen etwas schief gegangen) könnte so ein Supervisor-Chip den Reset auslösen bevor geschrieben wird.
Dieter schrieb: > Ich verstehe noch nicht warum beim defekten Gerät ein leerer EEPROM > nicht auch mit Default-Werten initialisiert wird. Es wird im IBL zwar Exakt das wundert mich ja auch! Von einer solchen Funktion bin ich ja erst garnicht ausgegangen, bis ich es einfach mal probiert hatte! Zuvor waren wir ja der Überzeugung der Inhalt muss stimmen und passen, sonst geht es nicht weiter. Aber das ist ja definitiv nicht der Fall. Solch ein Verhalten kenne ich aber auch vom Ford Navigationssystem, da hat das EEPROM auf dem Mainboard eine ähnliche "Funktion". Was auch immer da gespeichert wird, es behindert nicht den Start. Selbst wenn ich "Müll" reinschreibe, wird das einfach wieder überbügelt. > der Watchdog gestartet, der sollte aber erst nach einigen Sekunden einen > Reset auslösen und so lange dauert es ja nicht bis das EEPROM Lesen > wieder von vorne los geht. Verstehe... > Interessant wäre zum vergleichen der IBL aus dem funktionierenden Gerät, > der ist ja leider nicht in der USB Firmware-Update Datei enthalten. Nur > macht es vermutlich wenig Sinn auch beim funktionierenden Gerät den > Flash auszulöten solange nicht sicher ist dass man damit auch wirklich > neue Erkenntnisse über die Abläufe gewinnt. Der "Sinn" wäre mir noch egal, der Punkt ist, das sich die Flashs extrem schlecht aus und noch schlechter wieder einlöten lassen. Da musste ich ganz schön rumfuhrwerken damit das wieder halbwegs ordentlich ist. Da sind teils Bauteile so dicht an die Pins gesetzt das man selbst bei einer 0.8er Spitze kaum dazwischen kommt. Auch nehmen die Pins sehr schlecht das Lot an, weil darunter vermutliche große Masseflächen sitzen die die Hitze schlucken. Und solch einem gebrutzel besteht zu stark die Gefahr das man Pads abreiß und dann ist Feierabend. Daher suchte ich ja nach einem Weg den JTAG vom CP3CN37 zu nutzen um an den Flash-Inhalt zu kommen. Es würde mich schon interessieren, wenn man das funktionierende Modul mit der entsprechenden USB-Datei updated und dann die Flashs ausliest, was er wo hineinschreibt.
Winfried J. schrieb: > Eventuell doch ein HW-Defekt? Tja, das ist die Frage. Wir glauben bislang das die Software im Flash der MPU soweit okay sei. Wir wissen es aber nicht genau weil es keinen Vergleichswert gibt. Daher spricht im Moment alles dafür das es noch eine Randbedingung für den Start gibt und das diese nicht erfüllt ist und daher der EEPROM-Inhalt nicht zurückgeschrieben wird, sondern gleich wieder in einen erneuten Lesevorgang gesprungen wird. Das wirkt eigentlich so, als würde sich der Chip nach erfolgtem einlesen selbst resetten. > Es wäre z.B. denkbar, dass an der MCU der MISO Input defekt ist und das > Signal auf der Leitung intern nicht weiterverarbeitet werden kann. Theoretisch möglich, aber wenn der Input defekt wäre würde die Software vermutlich nur 1en oder 0en erkennen. In beiden Fällen müsste sie dann nach dem lesen versuchen den EEPROM neu zu beschreiben. Das macht sie übrigens auch wenn die Daten vom EEPROM ok sind. Und auf gut Glück mal einen TQFP174 verpflanzen... das ist kein Spaß. Wenn man doch nur halbwegs einen JTAG-Debugger hätte, dann könnte man evtl. herausfinden welche Operationen der Chip ausführt, bzw. die SPI-Register befüttern und schauen ob MISO funktioniert. Leider konnte ich nichts finden wie man einen OpenOCD oder Segger J-Link dazu verwenden könnte.
:
Bearbeitet durch User
Dieter schrieb: > Es gibt ja noch ein paar nicht identifizierte, kleinere Chips, Ich habe alle bisher identifizierten, inkl. Datenblatt hier auf meiner Wiki-Seite hinterlegt: https://mk4-wiki.denkdose.de/artikel/audio_navigation/sound_connect/innenleben Da sind noch ein paar weiße Flecken auf der Landkarte. Vielleicht findet ja noch jemand was dazu...
Angehängte Dateien:
-
c57.jpg
130 KB
Dieter schrieb: > Eine weitere Idee: Ich sehe dass im IBL an diversen Stellen Bit 5 vom > Port-E (PE5 an Pin 3 der MCU) kurz auf "0" und dann wieder auf "1" > gesetzt wird. Ob das eventuell einen externen Supervisor-Chip triggert? Der geht an IC (13) Pin 6, der mit "C57" (und "16Z" darunter, was aber bei dem anderen Modul "88Z" ist, also eher eine Serie) gekennzeichnet ist. Es ist wohl ein SM8 Gehäuse mit 3x3 mm. Könnte ein SN74LVC2G157 SINGLE 2-LINE TO 1-LINE DATA SELECTOR/MULTIPLEXER sein.
:
Bearbeitet durch User
Olli Z. schrieb: > Könnte ein SN74LVC2G157 SINGLE 2-LINE TO 1-LINE DATA > SELECTOR/MULTIPLEXER sein. Ja, das passt, im Datenblatt steht auch das entsprechende "Device Marking". Ich denke ich habe jetzt den Mechanismus mit PE5 von Port-E verstanden, damit wird der Wert des Flip-Flop (SN74LVTH374) gesetzt an dem u.a. das Chip-Select für den EEPROM liegt, wie Du weiter oben schon beschrieben hast. Damit hat sich dann wohl auch die Idee eines externen Supervisor Chip erledigt. Was mir auch nicht klar ist im Zusammenhang mit dem EEPROM Schreiben: im defekten EEPROM wurde wohl irgendwann noch was sinnvolles geschrieben, die beiden letzten 512-Byte Blöcke haben eine gültige CRC. Im vorletzten Block steht der Fehlerspeicher, die zwei Einträge (zweimal "hw_start_ibl.c025B*") passen genau zu dem Fall dass aus dem IBL nicht in den PBL gesprungen wird weil an anderer Stelle im EEPROM ungültige Daten stehen. Also hat der IBL wohl irgendwann noch was geschrieben, nur warum er das jetzt nicht mehr macht (egal ob mit gültigen Blöcken oder vollkommen leer) verstehe ich noch nicht.
Nochmal eine Theorie zum aktuellen Problem: Könnte es sein dass beim Flash der MCU Adress-Pins nicht passen, also z.B. immer "0" sind? Hintergrund ist dass sich der IBL Code ja ganz am Anfang des Flash befindet. Belegt ist vom IBL nur der Bereich bis etwa 0x41C4. Sollte also eventuell einer der oberen Adress-Pins fest auf "0" stehen würde das im IBL nicht auffallen, erst später bei Zugriff auf höhere Adressen geht dann etwas schief. Mir gehen langsam die Ideen aus warum das defekte Geräte nicht das tut was man erwarten würde, daher solche vielleicht etwas "exotischen" Ideen.
Dieter schrieb: > Mir gehen langsam die Ideen aus warum das defekte Geräte nicht das tut > was man erwarten würde, daher solche vielleicht etwas "exotischen" > Ideen. Nun etwas Off-Topic, aber irgendwie auch nicht: An dieser Stelle muss ich Dir mal meinen allertiefsten Dank und ein großes Lob für Dein bisheriges Engagement aussprechen!!! Ohne Dich wäre ich garnicht so weit gekommen, das steht fest. Und selbst wenn hier schluß sein sollte (und das sehe ich noch nicht) hätte wir viel erreicht und gelernt und darum geht es in einem Forum doch am meisten, finde ich. Deine Ideen und Hinweise waren bislang alle wichtig und richtig. Fachlich hervorragend und haben immer weitergeholfen. DANKE! Ich bin jemand, der auch nicht so schnell aufgibt, auch wenn ich mal einen "durchhänger" habe. Dann lasse ich das Projekt etwas liegen und greife es später nochmal auf. Manchmal hilft auf Kollege Zufall oder jemand anders stolpert über den Thread und kann neuen Input liefern. Da es für mich reinies Hobby ist und ich hoffe damit mal anderen helfen zu können, muss es sich auch nicht rechnen oder besonders schnell gehen. Ich glaube da gibt es noch einiges was wir uns anschauen und testen können! Ich hätte auch ein weiteres BK-Modul gekauft, das wär mir wurscht gewesen die 100,- €. Hier gehts mir schon lange ums Prinzip. Leider sind ausgerechnet die Nokia BK Module praktisch nicht aufzutreiben. Einen einzigen Anbieter auf allegro.pl konnte ich ausmachen. Aber irgendwie komme ich auf diesem Marktplatz nicht zum Zuge.
Dieter schrieb: > Olli Z. schrieb: > Ich denke ich habe jetzt den Mechanismus mit PE5 von Port-E verstanden, > damit wird der Wert des Flip-Flop (SN74LVTH374) gesetzt an dem u.a. das > Chip-Select für den EEPROM liegt, wie Du weiter oben schon beschrieben > hast. Dieses /CS Multiplexing am SPI-Bus ist ja drübergestülpt, weil die Entwickler wohl Ports sparen wollten und nicht für jeden externen Baustein einen Port für das CS bereitstellen, bzw. die externen Chips in ähnlicher Art wie die internen Komponenten einfach über Adressen ansprechen wollten. > Was mir auch nicht klar ist im Zusammenhang mit dem EEPROM Schreiben: im > defekten EEPROM wurde wohl irgendwann noch was sinnvolles geschrieben, > die beiden letzten 512-Byte Blöcke haben eine gültige CRC. Im vorletzten Wenn Du sagst "gültige CRC", woher willst Du das denn wissen? Weißt Du wie sich die CRC berechnet? Wenn ja, bitte mal den Algo nennen, das wäre doch sehr interessant! > Block steht der Fehlerspeicher, die zwei Einträge (zweimal > "hw_start_ibl.c025B*") passen genau zu dem Fall dass aus dem IBL nicht Ok, dann ist die hintere Hex-Zahl ein DTC Fehlercode oder sowas? Im Ford wäre "C" der Code fürs Chassis, jedoch gibt es offiziell kein "025B". Vielleicht ist es ja auch etwas internes. Aber die Theorie gefällt mir! > Also hat der IBL wohl irgendwann noch was geschrieben, nur warum er das > jetzt nicht mehr macht (egal ob mit gültigen Blöcken oder vollkommen > leer) verstehe ich noch nicht. Genau das ist die Frage. Es muss also noch irgendwas geben, was der IBL nach dem einlesen der EEPROM-Daten prüft und dies führt im defekten Modul eben zum Problem. Ich werde mal versuchen herauszufinden wann sich die zusätzlichen Komponenten auf dem Modul aktivieren, sprich wann geht der DSP ins Rennen, wann der Bluetooth-Chip. An der Stromverbrauchskurve erkennt man, das diese nicht bereits beim Start mit starten, also werden die, wie fast im Automotive-Sektor üblich, durch die MPU gestartet, über eigene Spannungsregler. Vielleicht bringt uns das ja weiter? So gern würde ich Dir beim disassemblen helfen, aber zum einen fehlt mir immernoch ein Plugin, zum anderen habe ich wohl nicht so viel Erfahrung damit wie Du. Ich werde meine Bemühungen auf den Bereich Debugging richtigen, also das SDI-Interface via JTAG resp. UART.
Olli Z. schrieb: > Wenn Du sagst "gültige CRC", woher willst Du das denn wissen? Weißt Du > wie sich die CRC berechnet? Wenn ja, bitte mal den Algo nennen, das wäre > doch sehr interessant! Siehe die angehängte Datei. Den CRC Code habe ich mit "pycrc" erzeugt, die CRC Tabelle mit den Werten findet man auch im Binary. Wie schon beschrieben, der EEPROM ist in 512 Byte große Blöcke unterteilt, wenn am Ende der Marker 0xABCD steht gibt es eine CRC davor. Die Länge für die CRC Berechnung hängt vom Block ab, in der angehängten Datei stehen die Block-Längen für beide Geräte. Olli Z. schrieb: > Ok, dann ist die hintere Hex-Zahl ein DTC Fehlercode oder sowas? Im Ford > wäre "C" der Code fürs Chassis, jedoch gibt es offiziell kein "025B". > Vielleicht ist es ja auch etwas internes. Aber die Theorie gefällt mir! Das ist die Sourcecode Datei ("hw_start_ibl.c") plus vermutlich Zeilennummer in HEX (025B) plus ein Byte Code (0x2A). Das wird so als Parameter an die Funktion zum Schreiben des Fehlers übergeben, wobei der komplette Dateiname inklusive Pfad ("..\..\Target\mcu\pf_p1573\HAL\Octavia_CP3BT30\driver\hw_start_ibl.c") übergeben wird, der dann aber gekürzt wird. Dieser spezielle Fehler wird geschrieben wenn der IBL nicht in den PBL springt weil an anderer Stelle im EEPROM Block 0 nicht die erwarteten Marker stehen. Ich gehe mittlerweile stark davon aus dass irgendetwas beim Ausführen des Code schiefgeht (siehe meine Idee bezüglich Adress-Pins des Flash). Ich sehe im IBL nichts mehr was erklären könnte dass nicht in den EEPROM geschrieben wird, entweder weil Default-Werte gesetzt werden oder weil ein Fehler geschrieben wird.
Dieter, würdest Du mir das Disassemblat mal per Mail zukommen lassen? Kontakt z.b. über das Forum
Olli Z. schrieb: > Dieter, würdest Du mir das Disassemblat mal per Mail zukommen lassen? Da stehen meine Anmerkungen und Notizen drinnen, die gebe ich nicht weiter. Wenn Du es selber disassemblieren willst probiere halt Ghidra, das hat Unterstützung für den CR16C. Bezüglich des IBL aus dem defekten Gerät und das Verhalten bei leerem/ungültigem EEPROM Inhalt habe ich es inzwischen selber ausprobiert: Der EEPROM wird mit Default-Werten beschrieben und es wird der entsprechende Fehler eingetragen, der angibt dass kein Sprung in den PBL erfolgt weil die Marker in Block 0 nicht passen. Daher gehe ich davon aus dass irgend etwas anderes bei Deinem Gerät nicht stimmt wenn das nicht so abläuft. Unabhängig davon wäre es interessant ob man auf der "BVC Low" Variante die Software von der "BVC High" zum laufen bekommt, damit sollte das Spielen von Musikdateien von einem USB-Speicher möglich sein. An Hardware fehlt der "BVC Low" ja nicht viel, auf GPS (fehlender Line-Driver und Power Supply) kann man vermutlich verzichten und wenn man keinen iPod anschließt stört der fehlende iPod Authentication Coprocessor (das ist vermutlich der Chip Nummer "8", von dem Du noch keine Bezeichnung angegeben hast) auch nicht. Natürlich ist das alles nur Spielerei, bei den relativ niedrigen Preisen für dieses Steuergerät lohnt sich das Ganze nicht wirklich.
Hallo, eine interessante Runde hier. Ich habe das gesamte WEB durchsucht um für das BT-Modul eine Leiterplatte zu sehen. Ich habe ebenfalls Störungen (aber keinen Total-Ausfall) am BT-Modul. Es scheint sehr häufig bei diesem Ford-Modell vor zu kommen. Ich bin auch kein Elektroniker oder Programmierer. Löte gelegentlich verbrannte Teile aus und ein und habe vor ein paar Hundert Jahren Turbopascal vom Schulkolegen abgeschrieben :-). Was mich an der ganzen Thematik beschäftigt. Warum ist der Ausfall eher Zeit- bzw. Verschleißbedingt? Sehr oft beginnend mit Stromfraß. Das dürfte doch nur Hardwareseitig sein wenn sich entweder ein Elko, Relais oder Mosfet verabschiedet. Worüber ich auch schon nachgedacht habe, ist wenn ein USB-Stick stecken bleibt, der frisst doch weiterhin Strom. Wenn dessen Ruhestrom hoch genug ist, dass jemand auf der Leiterplatte keinen Grund bekommt herunter zu fahren. Grüße Nold
Es können auch Aliensporen sein die auf subatomarer Ebene die IO-Pins verstopfen... ;-) Spaß beiseite, die Frage WARUM etwas kaputt geht driftet schnell ins philisophische ab. Mich (uns) hier treibt eher die Frage um, herauszufinden was konkret den Regelbetrieb verhindert. Und da gibt es grundsätzlich zwei Ansätze: Einer bei dem man rein auf elektronischer Ebene überprüft, also Bauteile, Spannungen, Signale. Und der andere indem man versucht die Programmabläufe zu verstehen und evtl. Debug-Schnittstellen zu finden in der Hoffnung den Startverhinderungsgrund definitiv zu wissen. Gut möglich das irgendein Bauteil auf dem Modul hinüber ist, aber das wird sich irgendwo in der Software wiederspiegeln. Daher der Ansatz von Dieter, völlig zurecht die Software zu debuggen und darüber haben wir dann ja auch so einiges ermitteln können.
Nachdem unsere Versuche hier mit dem EEPROM das Startproblem leider auch nicht lösen konnten komme ich nochmal auf JTAG zurück. Ziehmlich zu Anfang dieses posts habe ich ja bereits die am MCU verfügbaren JTAG-Pins am Header auf der Unterseite gefunden: Olli Z. schrieb: > Anbei erstmal die JTAG-Pinbelegung. Leider habe ich dort keinen RESET > gefunden, aber den kann man natürlich auch mittels JTAG-Kommando > auslösen. und konnte mit dem Segger wenigstens eine JTAG-ID vom Chip erhalten: > Ein Probe auf dem JTAG ergab: > TotalIRLen = 8, IRPrint = 0x0001 > JTAG chain detection found 1 devices: > #0 Id: 0x0FB1501F, IRLen: 08, Unknown device Aber da der Segger diesen Typ MCU nicht direkt unterstützt kann man damit leider erstmal nichts tun: > ****** Error: CPU-TAP not found in JTAG chain > > Cannot connect to target. Das einzige was ich vom Datenblatt her weiss ist des es sich um eine RISC-CPU vom Typ CR16C handelt. Meine Hoffnung ist den externen App-Flash über den CP3CN per JTAG neu flashen zu können. Löten ist echt übel weil da dicke Masseflächen sind (habs schonmal probiert) und ich hab Sorge pads abzureissen.
Dieter schrieb: > Unabhängig davon wäre es interessant ob man auf der "BVC Low" Variante > die Software von der "BVC High" zum laufen bekommt, damit sollte das Ja, das wäre in der Tar eine interessante Option. Ich weiss von Leuten die einfach versucht haben die Firmware via CAN (UCDS) aufzuspielen, aber ohne Erfolg. Ich vermute das die Hardware-Revision irgendwo kodiert ist und das verhindert. > Spielen von Musikdateien von einem USB-Speicher möglich sein. An > Hardware fehlt der "BVC Low" ja nicht viel, auf GPS (fehlender > Line-Driver und Power Supply) kann man vermutlich verzichten und wenn Wozu sollte das Modul denn GPS haben? Ich wüsste da keine Anwendung im Ford... > man keinen iPod anschließt stört der fehlende iPod Authentication > Coprocessor (das ist vermutlich der Chip Nummer "8", von dem Du noch keine Bezeichnung angegeben hast) auch nicht. Soweit ich das entziffern kann "V112 AA 08K CF6Q G4"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.