Ich bin gerade dabei, eine Firmware für E-Bike Controller der Fa. Bafang zu schreiben. Über SWD geflasht funktioniert das bereits, es ist aber für Otto-Normal-User eine riesige Hürde, den Controller auseinanderzuschrauben, ggf. Vergussmasse wegzupulen um dann einen SWD Programmer anzuschließen. Bafang macht Firmwareupdates über CAN. Tool und Firmwarefiles findet man einfach im Internet. Jetzt möchte ich es ermöglichen, die offene Firmware über diesen Weg zu flashen. Da die Prozessoren nicht lesegeschützt sind, kann man sie leicht auslesen. Die offiziellen Update-Files werden 1:1 in den Flash-Speicher geschrieben, da ist also zum Glück nichts verschlüsselt. Das Programm startet offensichtlich an Adresse 0x08004000, auch wenn noch 32 Bytes davor geschrieben werden, die aber wohl nur zum Abgleich der Hardwareversion dienen. Ich habe mir jetzt gedacht, ich schreibe meine Firmware einfach an diese Startadresse und der Bootloader springt die dann schon an, leider rebootet der Prozessor so ständig. Im Bootloader blinkt eine LED auf dem Board nervös, daher kann man das schön sehen. :-( hier gibt es den Flash-Dump des Controllers, ein Bafang-Update-File und natürlich mein Projekt: https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6/commit/77195818d6f7622e33b4172cb34941b24be92ce8 Ich habe es mit einem anderen Bootloader probiert, da hat es funktioniert, das Verschieben der Startadresse und der Interrupt-Vektor Offset scheinen korrekt implementiert zu sein. Auch wenn es interessanterweise relevant ist, an welcher Stelle im Code der Interrupt-Vektor Offset gesetzt wird. Direkt als erstes nach dem int main(void){ geht es nicht, gleich am Anfang der SystemInit() Funktion geht es.... Hat jemand eine Idee, warum der Prozessor immer rebootet? Ist das eher ein Bug in meinem Programm, das ständig einen Reset auslöst, oder checkt der Bootloader irgendwie, ob eine bekannte Firmware vorliegt und wenn der Check fehlschlägt, wird rebootet? Gruß hochsitzcola
Hochsitz C. schrieb: > Hat jemand eine Idee, warum der Prozessor immer rebootet? Im Debugger geprüft ob dein Code (Reset_Handler) überhaupt gestartet wird? Erwartet der Bootloader eine Checksum (CRC)?
Genau, habe das schon irgendwo mal gelesen... hier (NationZ) Beitrag "Re: ALLPOWERS S2000 PRO Reparaturhilfe"
Niklas G. schrieb: > Im Debugger geprüft ob dein Code (Reset_Handler) überhaupt gestartet > wird? Ja, der Reset Handler wird angesprungen. https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6/blob/77195818d6f7622e33b4172cb34941b24be92ce8/gcc_startup/startup_gd32f30x_hd.S#L23 also wird es wohl nicht am Bootloader liegen, sondern an meinem Code liegen?
:
Bearbeitet durch User
Hochsitz C. schrieb: > also wird es wohl nicht am Bootloader liegen, sondern an meinem Code > liegen? Klingt so. Ist doch super, debugge es step-by-step und du siehst wo es rausfliegt. Ggf. direkt am Anfang vom Reset_Handler die Interrupts abschalten (cpsid i), eventuell macht der Bootloader das nicht und irgendeine aktivierte Peripherie löst einen Interrupt aus der ins Nirvana geht. Auch immer das VTOR im Auge behalten. Vielleicht ist auch Takt, Flash Wait States, ... Komisch konfiguriert vom Bootloader was dein Programm nicht mag.
Ich werde wohl erst mal mit einem einfachen Blink-Beispiel anfangen, um zu schauen, ob das prinzipiell läuft, oder doch irgendwie der Bootloader reinspuckt.
Das war leider nicht erfolgreich. Ich habe ein ganz einfaches Programm geflasht, daß einfach nichts tut, nur eine Endlosschleife ohne weitere Aktivität, auch dann rebootet der Prozessor ständig. Scheint also doch irgendeine Abfrage vom Bootloader zu sein. Wie kann man so etwas auf die Spur kommen? Ich bekomme auch den ständigen Neustart mit dem Debugger gar nicht angehalten...
:
Bearbeitet durch User
In den RCU_RSTSCK Flags prüfen, ob ein Watchdog den Reset ausgelöst hat. Wenn da ein Watchdog aktiviert ist muss der ge-serviced werden.
Hm, der Watchdog scheint es nicht zu sein. Der Zähler WWDGT_CTL steht immer auf 127, was der Default-Wert zu sein scheint. RCU_RSTSCK hat den Wert 2, also nur das Signal, daß der Takt stabil ist.... https://download.gigadevice.com/User_Manual/GD32F30x_User_Manual_Rev3.4.pdf
Hardware Watchdog auf der Platine vielleicht ?
Der müsste ja auch anspringen, wenn ich meine Firmware von 0x08000000 starte, da läuft sie aber problemlos. Ich habe auch das WWDGT_HOLD Flag im DBG_CTL0 Register gesetzt, der Prozessor bootet trotzdem ständig neu auf wenn der Debugger auf Pause steht :-(
Hochsitz C. schrieb: > RCU_RSTSCK hat den Wert 2, also nur das Signal, daß der Takt stabil > ist.... Das lässt sich imo aber nur so erklären, dass der Bootloader die Flags löscht. Zumindest PORRSTF sollte sonst ja gesetzt sein. Zusätzlicher Hardware-watchdog ist bei einem E-Bike-Controller schon auch denkbar. Ansonsten mal Breakpoints an den Anfang von allen Exception Handlern streuen und den Bootloader entry point. Mit letzterem kann man dann auch die ungelöschten Reset Flags in RCU_RSTSCK abgreifen.
Benedikt H. schrieb: > und den Bootloader entry point. Da muss ich erst mal schauen, wie man das mit Open GDB macht, ich debugge aus dem Eclipse-basierten GDEmbeddedBuilder
Niklas G. schrieb: > Adresse des Reset Handler des Bootloaders angeben Wie bekomme ich die heraus?!
:
Bearbeitet durch User
Hochsitz C. schrieb: > Wie bekomme ich die heraus?! Steht im Interrupt-Vektor an Stelle 1, d.h. in Bytes 4-7 des binary Image. Little Endian natürlich.
Danke, das wäre 0x080001B1, dann probiere ich das mal...
Hochsitz C. schrieb: > 0x080001B1 Probier ggf. 0x080001B0, hab nicht im Kopf ob es mit 0x080001B1 geht beim GDB. Die tatsächliche Adresse ist natürlich immer gerade, das unterste Bit wird bei Sprungzielen (wie hier im Interrupt-Vektor) auf 1 gesetzt und anzuzeigen dass dort Thumb-Code liegt. Beim Cortex-M eine gerade Adresse anzugspringen ist übrigens auch ein Grund für einen Crash, weil die CPU den "ARM" Code nicht unterstützt.
:
Bearbeitet durch User
Angehängte Dateien:
-
Sceenshot.PNG
17 KB
Ich krieg den Breakpoint hin, aber kann in diesem Zustand den RCU_RSTSCK nicht lesen, in den Expressions wird der Wert nur angezeigt, wenn der Breakpoint im eigenen Code liegt. Das geht doch alles deutlich über das hinaus, was ich bisher mit Mikrocontrollern gemacht hab :-)
Hochsitz C. schrieb: > aber kann in diesem Zustand den RCU_RSTSCK nicht lesen Auf der GDB Konsole: x/1xw 0x123... Adresse des gewünschten Registers angeben.
In der Eclipse gibt's da die Debug Console oder evtl geht's über Variables/Expressions
Thomas W. schrieb: > In der Eclipse gibt's da die Debug Console oder evtl geht's über > Variables/Expressions Die diversen IDEs zicken da manchmal und wollen sowas nicht ausgeben, warum auch immer. Wenn man direkt die GDB-Befehle eingeben kann umgeht man das
Angehängte Dateien:
-
Sceenshot1.PNG
21 KB
für RCU_RSTSCK wird volatile uint32_t *)(uint32_t)((((uint32_t)0x40018000U) + 0x00009000U) + 0x24U))angezeigt, sollte also 0x40021024 sein. aber das klappt irgendwie nicht... Das ganze Debuggen aus der Kommandozeile starten würde vielleicht besser gehen?
:
Bearbeitet durch User
Hochsitz C. schrieb: > aber das klappt irgendwie nicht... Adresse ist falsch eingegeben (0x04... Statt 0x40...). Die CPU ist nicht angehalten? Klingt als wäre es bereits abgestürzt/neugestartet? Passiert das so auch wenn du nur dein Programm "normal" geflasht hast, und genau so direkt im Reset_Habdler angehalten? Ist die Spannungsversorgung stabil? Debuggen und auch Flashen braucht viel Strom, wenn die Spannung einbricht startet der Controller neu und der Debugger fliegt raus. Alternativ mal nen besseren Debugadapter verwenden (J-Link oder so).
:
Bearbeitet durch User
Der Debugger hält den Prozessor nicht an, die LED flackert immer weiter Ich hab den Befehl im falschen Fenster eingegeben. Im Fenster "Debugger Console" funkioniert es, aber keine neue Erkenntnis. x/1xw 0x40021024 0x40021024: 0x00000002 Das Debuggen meines Codes direkt ohne den Bootloader an Adresse 0x08000000 gestartet funktioniert einwandfrei.
:
Bearbeitet durch User
Hochsitz C. schrieb: > Der Debugger hält den Prozessor nicht an, die LED flackert immer weiter Da wird der Bootloader wohl das Debug Interface abschalten. Du könntest ganz am Anfang deiner software das Interface wieder einschalten und die BKPT Instruktion nutzen um das Programm garantiert anzuhalten.
Niklas G. schrieb: > Da wird der Bootloader wohl das Debug Interface abschalten. Hm, aber der Debugger kommt ja dazwischen um die Firmware zu flashen und die Session zu starten. auch mit einem __asm__("BKPT #01"); ganz am Anfang meines Codes rebootet der Prozessor fröhlich weiter xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 target halted due to breakpoint, current mode: Thread Wie würde man denn das Debug interface wieder einschalten? Ich habe da keinen Befehl zu gefunden :-(
:
Bearbeitet durch User
Lade doch mal den kompletten Flash-Dump mit dem "Blink" Testprogramm hier hoch (also alles inklusive dem Bootloader).
:
Bearbeitet durch User
Bitte schön! Die erst Datei ist nur der Bootloader ... ich habe auch noch die original Firmware drangehangen, die nicht rebootet, wenn man sie an die Startadresse 0x08004000 flasht.
:
Bearbeitet durch User
Hochsitz C. schrieb: > Hm, aber der Debugger kommt ja dazwischen um die Firmware zu flashen und > die Session zu starten. Hochsitz C. schrieb: > xPSR: 0x61000000 pc: 0x080066ba msp: 0x20001354 > target halted due to breakpoint, current mode: Thread > xPSR: Aber 0x080066ba ist doch gar nicht die Reset Handler Adresse vom Bootloader? Da wird nicht richtig unterbrochen. Der Stack Pointer sieht auch komisch aus. Du könntest versuchen im Original Bootloader Image die erste Instruktion durch BKPT zu ersetzen und dann im Bootloader manuell zu "emulieren". Dann durchsteppen und schauen wo es neu startet.
In einem ARM Simulator würde das Blink Programm aufgerufen, allerdings werden dabei eventuelle Beeinflussungen durch die Peripherie (IO) ignoriert. Im Bootloader findet man eine Funktion zum Berechnen einer 16-Bit CRC über den Bereich ab 0x8004000. Allerdings bin ich mir nicht sicher ob das eventuell nur beim Laden der Firmware über den CAN-Bus benutzt wird und dann nach dem Schreiben des Updates nicht mehr aufgerufen wird. Die 32 Byte vor 0x8004000 entsprechen den 32 Byte Header in der Firmware Update Datei, dort steht wohl auch die 16-Bit CRC (ab Offset 0x10 im Header), allerdings sind die Werte in der Firmware Update Datei und dann im Flash unterschiedlich. Auch hier ist noch nicht ganz klar warum das so ist. Gibt es denn ein offizielles Tool mit dem das Firmware Update durchgeführt wird? Dann könnte man versuchen das "Blink" Programm in eine Update Datei umzuwandeln und über das Update Tool zu schreiben. Die CRC Berechnung für die Firmware Update Datei kann man nachvollziehen und eine passende CRC in den Header schreiben. Nachtrag: Was auch noch wichtig ist: Der Bootloader startet den FWDGT ("Free watchdog timer") den muss man dann auch bedienen.
:
Bearbeitet durch User
Das Tool mit dem man die Firmware updaten kann, gibt es als Open Source https://endless-sphere.com/sphere/threads/bafang-canable-pro-master-discussion.128228/ Ich hatte die zwei Bytes 16 Bytes vor dem 0x8004000 von Hand gelöscht, das Original Programm läuft auch ohne. Wahrscheinlich wird da nur während des Firmwareupdates eine Checksumme geprüft. Wie wird denn der FWDGT bedient? Ich hatte mir nur das einzige Beispiel aus der GS Library angeschaut, das war nicht verdächtig... Der Zähler vom WWDGT_CTL steht immer auf 127 Kommt das hier her? https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/watchdog/wdt_fwdgt_gd32.c Das würde ja heißen, dass da ein RTOS läuft?
:
Bearbeitet durch User
Hochsitz C. schrieb: > Das würde ja heißen, dass da ein RTOS läuft? Möglich, wäre für den Bootloader aber recht ungewöhnlich.
Warum braucht es ein RTOS um periodisch einen Watchdog zu triggern? Der Booloader läuft im Prinzip in einem Loop und ruft dann immer wieder die Funktion zum Triggern des Watchdog auf. Probiere das halt auch mal in dem "Blink" Programm (0xAAAA nach FWDGT_CTL schreiben).
Hochsitz C. schrieb: > Wie wird denn der FWDGT bedient? Ich hatte mir nur das einzige Beispiel > aus der GS Library angeschaut, das war nicht verdächtig... Der Zähler > vom WWDGT_CTL steht immer auf 127 Schau ins & lese doch erstmal das User Manual und/oder nutze eine Internetsuche um ein Beispiel zu finden. Im User Manual unter 14.1.4. steht z.B.:
1 | CMD[15:0] Write only. Several different fuctions(sic!) are realized by writing these bits with different Values: |
2 | ... |
3 | 0xAAAA: Reload the counter |
Da steht also genau was du tun musst. Lies doch erstmal die vorhandene Doku und probiere aus ob das klappt. > Kommt das hier her? > https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/watchdog/wdt_fwdgt_gd32.c Warum sollte das da her kommen? Generische non-window Watchdogs sind überhaupt nichts exotisches und ausserhalb von Arduino-Gebastel werden die auch genutzt wenn man halbwegs irgendwelche Safety-Anforderungen hat. Da braucht man kein Zephyr um einen Watchdog zu nutzen. Noch ein Nachtrag: > Ich bin gerade dabei, eine Firmware für E-Bike Controller der Fa. Bafang zu > schreiben. Vom Thread lesen hab ich ehrlich gesagt das Gefühl, dass du da etwas "out of your depth" bist, zumindest aber eine nicht so flache Lernkurve vor dir hast 😅
:
Bearbeitet durch User
Kleiner Teilerfolg, ich habe mir den falschen Watchdog angeschaut. Ich hatte nur den wwdgt auf dem Schirm, genutzt wird anscheinend der fwdgt. Wenn ich ganz zu Anfang meines Codes den Watchdog auf deutlich längere Zeiten setze, kommt der Reboot deutlich später
1 | fwdgt_config(65000, FWDGT_PSC_DIV256); |
aber das normale Programm, in dem ich den fwdgt in der Haupschleife und in den Interrupts mit fwdgt_counter_reload(); zurücksetze, läuft trotzdem nicht.... :-( Update: ich habe festgestellt, daß sich der Prozessor im ADCinit aufhängt. Konkret in der Funktion
1 | void delay_1ms(uint32_t count) |
2 | {
|
3 | delay = count; |
4 | |
5 | while(0U != delay){ |
6 | }
|
7 | }
|
Wenn ich das while auskommentiere, läuft die Hauptschleife, es kommt kein Reset mehr, aber es kommen keine Interrupts. Aber immerhin ein Fortschritt....
:
Bearbeitet durch User
so, Problem gelöst. Anscheinend deaktiviert der Bootloader die Interrupts. Mit
1 | nvic_vector_table_set(NVIC_VECTTAB_FLASH, 0x4000); |
2 | __enable_irq(); |
gleich am Anfang der main() läuft es jetzt. Vielen Dank für die hilfreichen Tipps! Bleibt noch herauszufinden, wie die Checksumme für das Flashen berechnet wird, damit über das Bafang Canable Tool keine Fehlermeldung kommt. Das Flashen funktioniert zwar, schließt aber mit einer Fehlermeldung ab.
:
Bearbeitet durch User
Hochsitz C. schrieb: > Bleibt noch herauszufinden, wie die Checksumme für das Flashen berechnet > wird, Wahrscheinlich nutzt der Bootloader die CRC-Peripherie des Controllers. Die implementiert CRC32 mit Ethernet Polynom. Leider ist nicht dokumentiert in welcher Reihenfolge die Bits verarbeitet werden, und ob Eingabe/Ausgabe invertiert ist. Das kannst du aber ziemlich simpel ausprobieren, da du ja ein Image mit korrekter CRC vorliegen hast. Versuch mal: - In C die crc32_z Funktion der zlib - In Python binascii.crc32 Probier alle Kombinieren aus: - Initialwert 0 oder 0xFFFFFFFF - Endergebnis invertiert oder nicht - Die Bits eines jeden 4-Byte-Words umgedreht Such im Bootloader Image mal nach 0x40023000 (Bytes tauschen für Little Endian), das ist die Adresse der CRC-Peripherie. Da drum herum könnte man den Algorithmus "ablesen".
:
Bearbeitet durch User
Ich habe hier bereits beschrieben dass der Bootloader die 16-Bit CRC berechnet. In der Firmware Update Datei "MMG522C4814F802010.1-CR X10N.510.FC 2.0 20240131.bin" (von Github https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6) ist die CRC 0xD20A (Datei Offset 0x10). Mit z.B. "reveng" kann man das so berechnen:
1 | reveng -w 16 -p 1021 -i 0000 -c -f firmware.bin |
"firmware.bin" ist dabei die eigentliche Firmware ohne den 32-Byte Header.
:
Bearbeitet durch User
Prima, Danke! Dann probiere ich mal aus, ob das Firmware Update so ohne Fehlermeldung klappt.
Dieter S. schrieb: > Ich habe hier bereits beschrieben dass der Bootloader die 16-Bit CRC > berechnet. Huh, kurios, verschenktes Potential - weniger effizient und weniger sicher als die Hardware CRC32 zu nutzen.
Angehängte Dateien:
-
Sceenshot2.PNG
45 KB
Dieter S. schrieb: > "reveng" kann man das so berechnen Hat funktioniert! Ich bin begeistert! Danke für die Unterstützung!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.