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.
von Olli Z. (z80freak)


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
von René F. (therfd)


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).

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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

von Peter (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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

von Olli Z. (z80freak)


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
von Dieter (Gast)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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.

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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.

von abc. (Gast)


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.

von Olli Z. (z80freak)


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.

von Dieter (Gast)


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?).

von Olli Z. (z80freak)


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?

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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.

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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
von Olli Z. (z80freak)


Angehängte Dateien:

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

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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).

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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.

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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.

von Dieter (Gast)


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").

von Olli Z. (z80freak)


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?

von Olli Z. (z80freak)


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.

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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).

von Olli Z. (z80freak)


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.

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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 ;-)

von Dieter (Gast)


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.

von Dieter (Gast)


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.

von Olli Z. (z80freak)


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
von Dieter (Gast)


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.

von Olli Z. (z80freak)


Angehängte Dateien:

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

von Olli Z. (z80freak)


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

von Dieter (Gast)


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

von Olli Z. (z80freak)


Angehängte Dateien:

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


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

von Dieter (Gast)


Angehängte Dateien:

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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


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


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

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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
von Olli Z. (z80freak)


Angehängte Dateien:

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

von Dieter (Gast)


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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


Angehängte Dateien:

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


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

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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


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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
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
von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


Angehängte Dateien:

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


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

von Dieter (Gast)


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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


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

von Dieter (Gast)


Angehängte Dateien:

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

von Olli Z. (z80freak)


Bewertung
0 lesenswert
nicht lesenswert
Dieter, würdest Du mir das Disassemblat mal per Mail zukommen lassen? 
Kontakt z.b. über das Forum

von Dieter (Gast)


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

von Nold (Gast)


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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


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

von Olli Z. (z80freak)


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

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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