STM32F042 gecloned aber verhält sich seltsam

[Ralf G. (dougie)]

Moin zusammen,

ich habe eine kniffelige Aufgabe vor mir.

Es geht um ein Modul mit einem STM32F042F6P6, das nicht mehr hergestellt 
oder vertrieben wird. Eins von den Dingern hatte ich noch hier, also 
wollte ich versuchen das nach zu bauen.

Es handelt sich um einen CAN Bus Transciever, der irgendwelche Daten auf 
den CAN Bus sendet und möglicherweise auch empfängt.

Problem war, das der Flash Level 1 protected war und somit ein direktes 
Auslesen nicht möglich.
Mit dem berühmten Obermaier Papier vom Faunhofer Institut und einem 
Programm eines cleveren Programmierers aus Brasilien konnte ich die 
Daten des Flash dennoch auslesen.

Das hab ich mehrfach getan und die Dateien binär verlichen. Alle waren 
identisch. Von den 32k scheinen etwa die Hälfte belegt.

Jetzt hab ich die Platine nachgebaut und das Flash Programm aufgespielt, 
aber der STM verhält sich seltsam.
In der Orginalschaltung hat die LED nach Anlegen der Spannung 
geleuchtet. Bei meiner Schaltung glimmt sie manchmal, manchmal glimmt 
sie nur kurz, und manchmal ist sie aus.

Wenn sie glimmt ist ein gepulstes Signal auf der Leitung mit 4ms 
Taktrate, aber es werden einzelne Wörter unterschiedlicher Länge 
gesendet.

Der Ausgang für den CAN Bus Chip ist stumm.

Ich hab testweise einen 8MHz Quarz / 33pF angelötet, aber der schwingt 
nicht. War der Versuch zu testen, ob etwas falsch konfiguriert ist und 
der interne Oszillator nicht stabil läuft.

Frage: was könnte ich falsch gemacht haben? Wenn der STM am STLink 
Debugger hängt, kann ich den anhalten und step für step das Programm 
laufen lassen und sehe, wie sich die ganzen Register verändern. Er 
scheint also irgendwas zu machen.

Hat jemand ne Idee?

VG
Ralf

[John P. (brushlesspower)]

Ralf G. schrieb:
> Frage: was könnte ich falsch gemacht haben? Wenn der STM am STLink
> Debugger hängt, kann ich den anhalten und step für step das Programm
> laufen lassen und sehe, wie sich die ganzen Register verändern. Er
> scheint also irgendwas zu machen.

Leuchtet die LED wenn der Debugger dran hängt?

Ralf G. schrieb:
> Hat jemand ne Idee?

Bist du dir sicher, dass du alles korrekt nachgebaut hast?

Ralf G. schrieb:
> Mit dem berühmten Obermaier Papier vom Faunhofer Institut und einem
> Programm eines cleveren Programmierers aus Brasilien konnte ich die
> Daten des Flash dennoch auslesen.

Wozu braucht es einen Programmierer aus Brasilien? Das Fraunhofer hat 
doch alles veröffentlicht inklusive Programm.
Sicher das er keinen Mist gebaut hat?

[J. S. (jojos)]

Funktioniert denn der neue Controller auf einer alten Platine?

[Cyblord -. (cyblord)]

Ralf G. schrieb:
> Problem war, das der Flash Level 1 protected war und somit ein direktes
> Auslesen nicht möglich.
> Mit dem berühmten Obermaier Papier vom Faunhofer Institut und einem
> Programm eines cleveren Programmierers aus Brasilien konnte ich die
> Daten des Flash dennoch auslesen.

Dieser Absatz zeigt mir schon genau wo das Problem liegt. Keine weiteren 
Fragen euer Ehren.

[Andreas B. (abm)]

Wenn die Original-Schaltung ohne Quarz bzw. externen Oszillator 
funktioniert, müsste der Nachbau das auch. Oszillator nutzen geht nur 
mit Anpassung der Software.

Flash kopieren reicht nicht. Die Option Bytes müssten auch mit kopiert 
werden.

Wenn RDP 1 gesetzt war, hat sich der Entwickler vmtl. etwas dabei 
gedacht ...
(sofern es nicht eine Trivial-SW ist und der Entwickler einfach nur 
gemein sein wollte). Z. B. könnte man ein zentrale Routine, die man 
ohnehin gern im RAM hätte, veschlüsselt im Flash ablegen, und erst beim 
Sytemstart entschlüsseln und ins RAM schreiben. Wenn der Schlüssel dann 
von der UID (s. RM0091, 33.1) abgeleitet wird, muss man den Ablauf 
erstmal verstehen, um das umgehen zu können.

[John P. (brushlesspower)]

Andreas B. schrieb:
> Z. B. könnte man ein zentrale Routine, die man
> ohnehin gern im RAM hätte, veschlüsselt im Flash ablegen, und erst beim
> Sytemstart entschlüsseln und ins RAM schreiben. Wenn der Schlüssel dann
> von der UID (s. RM0091, 33.1) abgeleitet wird, muss man den Ablauf
> erstmal verstehen, um das umgehen zu können.

Könnte.
Wissen wir nicht.

Andreas B. schrieb:
> Flash kopieren reicht nicht. Die Option Bytes müssten auch mit kopiert
> werden.
>
> Wenn RDP 1 gesetzt war, hat sich der Entwickler vmtl. etwas dabei
> gedacht ...

Meistens setz die Firmware selber RDP 1 damit es in der Produktion nicht 
ausversehen vergessen wird.
Aber auch hier wissen wir es nicht.

[Ralf G. (dougie)]

Vielen Dank für die Anteilnahme :-)

...anbei mal ein Bild des Original-Moduls und in wie weit ich es 
analysieren konnte.

Die Unterseite der Platine war fest verklebt und ich wollte den µP nicht 
ablöten um drunter zu schauen.

Was ich vom Verhalten her noch sagen kann: wenn der Proz frisch 
beschrieben ist, hat man eine gute Chance das am LED Ausgang ein Signal 
ist. Das kann schon mal lange dann so bleiben, oder es geht nach einem 
Power Cycle aus. Dann bleibt es meist auch aus und an Adresse 
0x080006000 bis 080006014 stehen dann Daten wo vorher nichts stand.

Möglicherweise hab ich das übersehen, aber ich hatte keine 
Programm-Files beim Obermaier Papier gesehen. Und da meine 
Programmierkenntnisse bescheiden sind, hatte ich mich des Tools bei 
GutHub bedient.

Das verwendet einen piPico, der das anscheinend schnell genug 
beherrscht.
Ob der einen Bug hat, kann ich leider nicht beurteilen.
Sollte da aber Müll raus kommen, würde ich erwarten, das der STM gar 
nichts macht.

[John P. (brushlesspower)]

Ralf G. schrieb:
> Möglicherweise hab ich das übersehen, aber ich hatte keine
> Programm-Files beim Obermaier Papier gesehen. Und da meine
> Programmierkenntnisse bescheiden sind, hatte ich mich des Tools bei
> GutHub bedient.
>
> Das verwendet einen piPico, der das anscheinend schnell genug
> beherrscht.
> Ob der einen Bug hat, kann ich leider nicht beurteilen.
> Sollte da aber Müll raus kommen, würde ich erwarten, das der STM gar
> nichjts macht.

Dann gehe ich mal davon aus das alles ok ist.

Ralf G. schrieb:
> anbei mal ein Bild des Original-Moduls und in wie weit ich es
> analysieren konnte.

Ich frage mich ob die dafür wirklich Aufwand betreiben das zu sichern?


Also ich hab auch schonmal eine FW kopiert. In Flash selber war die UUID 
des STM32 hinterlegt. Wenn die UUID des Chips nicht mit der im Flash 
übereinstimmte machte das Gerät gar nichts mehr.

Also auch wenn du alles richtig machst, kann es sein das es nicht geht.

[J. S. (jojos)]

Muss PB8-boot0 nicht auf GND liegen? So startet der Controller eventuell 
in das Bootrom.

[Ralf G. (dougie)]

So wie ich das Datenblatt verstanden hab, kann man die Funktion auch via 
den Option Bytes festlegen, damit PB8 weiter verwendet werden kann.

Das STLink Tool bietet mir nicht viele Optionen an, aber nBoot0 und 
nBoot1 kann ich setzen. Hab ich mal probiert, aber ohne Erfolg (oder ich 
mach es falsch)

[John P. (brushlesspower)]

Ralf G. schrieb:
> Das STLink Tool bietet mir nicht viele Optionen an, aber nBoot0 und
> nBoot1 kann ich setzen. Hab ich mal probiert, aber ohne Erfolg (oder ich
> mach es falsch)

Wie ist es denn beim original?
Du kannst die Option Bytes auslesen. Nur nicht den Flash
(Und natürlich auf gar keinen Fall das RDP Level ändern)

[Ralf G. (dougie)]

John P. schrieb:
> Wie ist es denn beim original?

Das hab ich blöder weise vergessen auszulesen :-/

Das Ding war das letzte seiner Art und durfte auf keinen Fall kaputt 
gehen. Daher hab ich es wie rohe Eier behandelt.

Aber so viele mögliche Kombinationen gäbe es ja nicht.

[Ralf G. (dougie)]

...anbei mal die 32k aus dem Flash.

Ich persönlich kann leider so nicht viel erkennen.

[Dieter S. (ds1)]

Was macht denn das Teil genau?

Wie hier schon vermutet wurde macht die Firmware einen Test auf die 
Device ID (im Code ab 0x0800184C), da werden die Werte aus 0x1FFFF7AC 
und 0x1FFFF7B0 geprüft. Siehe z.B. hier für Details zur Device ID:

http://blog.gorski.pm/stm32-unique-id

Der Code zur Prüfung ist etwas komplexer, eventuell reicht es ja den 
Test einfach zu überspringen. Wenn der Test schief geht wird auf jeden 
Fall etwas in den Flash ab 0x08006000 geschrieben, dort sollten wohl 
auch die Daten stehen, die für den Test auf die Device ID verwendet 
werden.

[John P. (brushlesspower)]

Ralf G. schrieb:
> Das Ding war das letzte seiner Art und durfte auf keinen Fall kaputt
> gehen. Daher hab ich es wie rohe Eier behandelt.

Das ist schlecht bei sowas.

Also du könntest mal die Option Bytes auslesen beim original mit einem 
STLink. Dabei sollte nichts passieren.

Du kannst deinen kopierten Chip und den originalen mal quer tauschen.
Funktioniert der originale auf der Kopierten Platine?
Funktioniert der kopierte Chip auf der original Platine?

ansonsten bleibt dir noch das flashen vom koperten Code in den 
originalen Chip -> wenn das geht gibt es irgendeine prüfung auf die UUID 
-> Viel Spaß beim suchen.

[Ralf G. (dougie)]

...ihr seid mal grossartig und macht dem Ruf dieses Forums wieder große 
Ehre. Danke noch mal für eure Hilfe.

Ich hab mir gerade mal ghidra installiert und geschaut, was für mich 
Sinn macht. Leider nicht besonders viel, weil das braucht wohl etwas 
mehr Zeit um es zu verstehen. Das meisste scheint unknown.

@Dieter ... mit ghidra kann ich die Funktion leider nicht erkennen. 
Womit hast du denn disassembliert? Abgesehen davon wüsste ich eh nicht 
welche Änderung ich im bin code machen müsste, das er das überspringt.
Mein Respekt und Hochachtung vor deiner Erfahrung.

Dazu kommt noch, das das Originalteil nicht mehr vorliegt. Musste ich 
dem Bekannten zurück geben. Aber ich kann fragen, ob ich es noch mal 
haben darf, sofern das die Chancen erhöht.

Was macht das Ding genau? Es emuliert ein Steuergerät indem es auf dem 
CAN Bus entsprechende Daten sendet.
Die CAN IDs sind 0028 und 04F6 mit Daten der Länge 8 byte

Was es stand-alone sendet, weiss ich. Das hab ich mitprotokolliert. Was 
ich nicht weiss ist, ob es auch auf irgendweche empfangenen Daten 
reagiert, da ich nicht in der Live-Umgebung (im Auto) testen konnte.

Ich hatte die Hoffnung, das die Flash Daten reichen würden.

VG
Ralf

[Dieter S. (ds1)]

Ralf G. schrieb:
>
> @Dieter ... mit ghidra kann ich die Funktion leider nicht erkennen.
> Womit hast du denn disassembliert? Abgesehen davon wüsste ich eh nicht
> welche Änderung ich im bin code machen müsste, das er das überspringt.

Das ist ganz normaler ARM (Thumb) Code den Ghidra ganz sicher 
disassemblieren kann (ich habe IDA Pro genommen, aber das ist im Prinzip 
egal, beide Tools sind vergleichbar).

Du könntest schauen was passiert wenn man das Byte an Offset 0x19AE in 
der Firmware duch 0x01 ersetzt (es ist im Original 0x00). Damit wird der 
Test auf die Device ID immer mit Erfolg beendet.

Ob das schon reicht kann ich nicht sagen. Die Funkion zum Test der 
Device ID ist bewusst komplex gehalten, eventuell macht die auch noch 
mehr was später für die eigentliche Funktion des Teils erforderlich ist 
(ich würde es zumindest so machen, z.B. könnte man aus der Device ID 
noch Daten errechnen die man später benötigt).

[Ralf G. (dougie)]

Du bist ist der Hammer, Dieter! :-)

Hab ich mal eben gemacht und siehe da: die LED ist an und bleibt auch 
an, wie beim  Original. Endlich stabil und nicht mehr mal so, mal so.

Aber es kommen noch keine Daten zum CAN Bus Chip. Das würde deine 
Einschätzung untermauern.

Weiterer Unterschied: das Programm verändert die Daten nach 0x80006000 
nicht mehr. Werte ich eigentlich als ein gutes Zeichen.

[Dieter S. (ds1)]

Werden denn von dem Teil CAN Messages verschickt ohne dass vorher etwas 
vom CAN-Bus empfangen werden muss?

Ich sehe auf die Schnelle nur dass die Firmware nach dem erfolgreichen 
Test der Device ID die Behandlung des CAN-Bus ausführt, dort gibt es 
dann auch die Funktionen zum Versenden der CAN IDs 0x4F6 und 0x028.

[Ralf G. (dougie)]

...ich hatte beim original Modul einfach meinen CAN Debugger angeklemmt 
(auf dem Tisch ohne Auto dran) und die Daten kamen automatisch. Ich 
werde das später noch mal unten im Labor testen. Aktuell häng ich noch 
am Schreibtisch mit meinem Hand-Scope. Nicht das das Billig-Teil nicht 
richtig triggert und ich was übersehe.

Von den beiden Platinen die ich gestern aufgebaut hab, hab ich mal die 
IDs ausgelesen. Leider fehlen mir die Daten des original Prozessors.

Und Ghidra ... ich bin nicht da wo du bist. Ich hab ARM v6 Little Endian 
genommen, aber bekomme nicht die Daten, die du vor dir hast. Oder ich 
bin zu blöd.

[Dieter S. (ds1)]

Zum Disassemblieren muss man den Dump an die richtige Stelle laden, das 
ist 0x08000000 bei diesem STM32 (Anfang des Flash), vielleicht liegt es 
ja daran.

[Ralf G. (dougie)]

....das macht einen DEUTLICHEN Unterschied :-D Dankeschön!

Jetzt sehe ich auch worüber du redest.

[Dieter S. (ds1)]

Nur zur Info, ich denke die gepatchte Firmware bedient den CAN-Bus. Ich 
habe das hier auf die Schnelle in einem Nucleo Board ausprobiert. Wenn 
man ohne CAN Transceiver arbeitet muss man CAN-Rx mit CAN-Tx verbinden, 
sonst passiert nichts. Macht man das aber sieht man Aktivität am 
CAN-Bus.

Was genau emuliert das Teil denn?

[Ralf G. (dougie)]

... ich hab es heute noch nicht in den Keller geschafft, aber jetzt freu 
ich mich auf morgen ... und bin dir zu allergrossem Dank 
verpflichtet!!!!
Kann ich mich irgendwie erkenntlich zeigen?

Was macht das Ding?

Im Range Rover L322 (und anderen) gibt es eine Lenksäule mit einem 
eigenen Steuergerät. Dieses sorgt u.a. dafür, das die motorbetriebene 
Lenksäulenverrigelung korrekt aus und ein gefahren wird.
Nach ausreichend vielen Jahren verharzt das und die 
Endlagen-Mikroschalter liefern keine korrekten Signale mehr und das 
Steuergerät meldet das.
Für die Wegfahrsperre bedeutet das, das sie nicht genau weiss, ob die 
Lenksäule jetzt verriegelt ist oder nicht. Und damit sperrt sie den 
Fahrzeugstart.
Reparieren kann man das nicht, weil das ein Alu-Klumpen ist. Lösung wäre 
eine neue Lenksäule....

Das Modul bedient sich eines Tricks. Nach Ab- uns Anklemmen der 
Autobatterie macht das gesamte System einen Grund-Reset und Entriegelt 
auf jeden Fall die Lenksäule. Dann zieht man den Stecker vom Steuergerät 
ab, und steckt das Modul drauf.

Somit kann man das Auto vor der Verschrottung bewahren.

[Dieter S. (ds1)]

Interessant, ich frage mich warum sie so viel Aufwand für den Schutz der 
Firmware betreiben.

Es sieht übrigens so aus dass im Fehlerfall (also wenn die Device ID 
nicht stimmt) über einen Pin vermutlich eine Audio Datei ausgegeben 
wird. Da ist relativ viel Code und Daten in der Firmware nur dafür, das 
wird auch nur benutzt wenn die Firmware in den Fehlerzustand geht.

[Ralf G. (dougie)]

....es hat mir keine Ruhe gelassen und ich musste das mal eben testen.

Es kommt leider noch nichts beim CAN Debugger an.

Irgendwo hab ich noch einen Bug... dein Setup hab ich nachgestellt und 
komme zum gleichen Ergebnis. Da tut sich was.

Aber ohne die RxD / TxD Brücke und mit dem CAN Bus Chip kommt nichts aus 
dem Prozessor.

TxD ist der Eingang des CAN Chips für die Daten, die zum Bus zu senden 
sind. Der hat einen internen 25k Pull-Up auf 5V .... da macht der 470R 
eigentlich keinen Sinn, um den STM32 zu entlasten. Den sollten die 25k 
nicht stören.

RxD ist ein CMOS Output mit den vom CAN Bus empfangenen Daten.

Da muss ich noch mehr nachdenken und prüfen...

[Schwierig (ruelps)]

Wenn Du R1 meinst, wird das nur ein Schutzwiderstand zur Strombegrenzung 
sein.

[Dieter S. (ds1)]

Ich habe einen CAN Transceiver an das Nucleo Board angeschlossen. 
Unmittelbar nach dem Reset legt die gepatchte Firmware mit dem Senden 
von 0x028 und 0x4F6 CAN Messages los, bei 500 kbit/s. Am CAN-Bus ist nur 
noch ein USB auf CAN Interface angeschlossen.

[Ralf G. (dougie)]

...dann stimmt bei mir noch was nicht.

Ich hab jetzt mal RxD und TxD vom Prozessor mit 470R verbunden, dann 
gibt es ebenfalls ein Ausgangssignal. Hast du noch was an den Option 
Bytes geändert?

Aber der CAN Bus Chip gibt kein brauchbares Signal raus. Vielleicht hab 
ich den kaputt getestet. Nachher mal tauschen.

Meinen CAN Debugger hab ich getestet. Der hat zwei Channel und mit einem 
Loopback Stecker funktioniert der einwandfrei.

[Dieter S. (ds1)]

Die Option Bytes sind der Default der ST-LINK Software. Eventuell den 
CAN-Bus terminieren, falls er das noch nicht ist.

[Ralf G. (dougie)]

LÄUFT!

TME hat mir tatsächlich eine Lieferung defekter CAN Transceiver 
geschickt. Kenne ich eigentlich nur von China. :-/

Meinen allerherzlichen Dank an ALLE Beteiligten und vor allem Dieter für 
seine Geduld, Erfahrung und Beistand! :-)

VG
Ralf