mikrocontroller.net

Forum: Fahrzeugelektronik Kennt jemand diesen Audio/CAN/BT Chip? CP3CN37VVAWQ


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: René F. (therfd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Antwort von TI war erwartungsgemäß negativ. Die behaupten dieses Bauteil 
garnicht (mehr) zu kennen :-|

Autor: Peter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00002000  49 42 4C 20 56 20 31 2E 32 31 30 0A 32 33 2D 30  IBL V 1.210.23-0
00002010  37 2D 30 38 0A 52 58 2D 34 32 0A 48 57 36 30 0A  7-08.RX-42.HW60.
00002020  28 63 29 20 4E 4F 4B 49 41                       (c) NOKIA

: Bearbeitet durch User
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 8, IRPrint = 0x0001
JTAG chain detection found 1 devices:
 #0 Id: 0x0FB1501F, IRLen: 08, Unknown device

****** Error: CPU-TAP not found in JTAG chain

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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: abc. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?).

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ups, da fehlte noch das Memorymap vom Flash (2)

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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").

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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):
/CS   (1) --> geht über 100 Ohm (und C nach Vcc) auf 6Q (15) vom 74374, 6D davon auf XD5 (43) vom CP3CN37
SO    (2) --> MDIDO (94)
/WP   (3) über Kondensator auf Vcc gezogen
SI    (5) --> MDODI (93)
SCK   (6) --> MSK (95)
/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:
0000 0001 (0x01) = Write status register
0000 0010 (0x02) = Write data to array
0000 0011 (0x03) = Read data from array
0000 0100 (0x04) = Reset write enable latch
0000 0101 (0x05) = Read status register
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
Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olli Z. (z80freak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
Time [s],Packet ID,MOSI,MISO
0.424679458333333,0,0x05,0xFF
0.424685666666667,0,0x00,0x00
0.424699708333333,1,0x03,0xFF
0.424703083333333,1,0x00,0xFF
0.424706458333333,1,0x00,0xFF
0.424713041666667,1,0x00,0x20
0.424715500000000,1,0x00,0x00
0.424717916666667,1,0x00,0xC4
0.424720375000000,1,0x00,0x22
...
0.444736958333333,1,0x00,0x6A
0.444739416666667,1,0x00,0xCD
0.444741833333333,1,0x00,0xAB
0.633914625000000,2,0x05,0xFF
0.633920250000000,2,0x00,0x00
0.633944916666667,3,0x06,0xFF
0.633955416666667,4,0x05,0xFF
0.633958958333333,4,0x00,0x02
0.633969583333333,5,0x02,0xFF
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
Autor: Dieter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.