RP ✔️ XiaoDeaDia - Unbrick (1s & pro2) ⛑️ ( Wiederherstellung ESC mit ST Link/V2 - Linux )

[Daniel_Gee]

!! ACHTUNG !!

AUS GEGEBENEN ANLASS DIESE VERSION BITTE NICHT AUSFÜHREN!

Hallo zusammen,

ich möchte euch heute mein kleines Projekt „XiaoDeaDia - unbrick & recover“ vorstellen.
Warum ich das Projekt XiaoDeaDia genannt habe ist schnell erklärt; „Xiao“ dürfte jedem ein Begriff sein und „Dea Dia“ steht für Wachstum, benannt nach einer römischen Göttin.

Was kann XiaoDeaDia - unbrick & recover; mit dieser Anleitung könnt ihr von einem funktionierenden ESC (1s und pro2) eine recover_ESC.bin oder eine recover_DRV.bin erstellen und natürlich auch wieder auf das ESC flashen.

WICHTIG;
Die recover_ESC/DRV ist nur zum persönlichen Gebrauch. Jede Firmware ist Eigentum der Herstellers.
Bitte auch das lesen; Nutzungsbedingungen, 8. Haftungsausschluss - Benutzeranleitungen / Guides / Tutorials & sonstige Rollerplausch Dienste

Die recover_ESC.bin enthält den gesamten Spreicher des ESC während die recover_DRV.bin nur die tatsächliche DRV Version darstellt. Solltet ihr mal irrtümlich eine falsche DRV auf das ESC geflasht haben, empfehle ich zum unbrick die recover_ESC.bin zu flashen.

Was ihr braucht ist einen ST-Link (Amazon/ST-Link) und einen PC oder Laptop.

Zum Betriebssystem; die aktuelle Anleitung ist für Linux, von mir an meinem pro2 getestet. Da überwiegend Windows verwendet wird, bekommt ihr noch hierfür nachträglich einen Anleitung.

Selbstverständlich darf jeder von euch mich unterstützen, es ist ein Projekt und für jeden/jede offen.

Für Linux müsste ihr nur OpenOCD installieren;
~$ sudo apt install openocd -y

Einen Treiber für den ST-Link wird in der Regel nicht benötigt, da die meisten Disto‘s diesen erkennen. Nachdem ihr den ST-Link angeschlossen habt, könnt ihr mit ‚~$ lsusb‘ die Port‘s abfragen. Für diesen Vorgang muss der ST-Link noch nicht an das ESC angelötet sein.

Es gibt noch andere Beiträge bezüglich verlöten und unbrick aber halt ohne recover (hier).

Wenn alles soweit läuft, müsst ihr den ST-Link mit dem ESC verlöten. Sicherlich gibt es auch die Möglichkeit mit Klebeband die Kabel zu befestigen aber davon rate ich ab (aber möglich).

Dann öffnet ihr zwei Terminal und platziert diese nebeneinander, so das sie sich nicht gegenseitig verdecken und los geht es;


Um eine recover_ESC.bin oder recover_DRV.bin zu erstellen, geht ihr wie folgt vor;

# Terminal 1 ~/
~$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg

# Terminal 2 ~/
# Terminal im ~/ öffen, da dort dann auch die recover_ESC.bin oder recover_DRV.bin gespeichert wird

# Terminal 2 ~/ telnet starten, damit kommt ihr dann auf die Befehlszeile für den stm32f1x (>>)
~$ telnet localhost 4444

# stm32f1x anhalten
>> reset halt

# stm32f1x schreibschutz deaktivieren
>> stm32f1x unlock 0

# Wenn ihr wollt, könnt ihr jetzt eine Speicherabfrage durchführen, raus kommt Offset und Größe oder ihr überspringt diesen Schritt
>> flash banks

# als erstes die recover_ESC.bin erstellen
>> dump_image recover_ESC.bin.bin 0x08000000 0x00020000

# als zweites die recover_DRV.bin erstellen, kann natürlich auch eine VLT sein
>> dump_image recover_DRV.bin 0x08001000 0x00006FFF

# beenden
>> reset

FERTIG!

Um die recover_ESC oder recover_DRV zu flashen, geht ihr wie folgt vor;

# Terminal 1 ~/
~$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg

# Terminal 2 ~/
# Terminal im ~/ öffen, da dort dann auch die recover_ESC.bin oder recover_DRV.bin gespeichert wird


# Terminal 2 ~/ telnet starten, damit kommt ihr dann auf die Befehlszeile für den stm32f1x (>>)
~$ telnet localhost 4444

# stm32f1x anhalten
>> reset halt

# stm32f1x schreibschutz deaktivieren
>> stm32f1x unlock 0

# recover_ESC.bin schreiben
>> flash write_image erase unlock recover_ESC.bin 0x08000000 bin

ODER

# recover_DRV.bin schreiben (ihr könnt hier auch eine ander DRV/VLT flashen, diese muss aber im ~/ liegen)
>> flash write_image erase unlock recover_DRV.bin 0x08001000 bin

# beenden
reset

FERTIG!

Bitte immer als erstes eine recover_ESC/DRV erstellen und diese bitte mit einem HexEditor, unter Linux verwende ich gerne Ghex (~$ sudo apt install ghex -y), unbedingt PRÜFEN.

Ein herzlichen Dankeschön geht an nandtek, Mentor und Unterstützer wie auch an VooDooShamane.

Gruß, Daniel

 

[3rzengel]

Sehr nett 👍

 

[nandtek]

Absolut genialer Guide Daniel_Gee!! Danke dir vielmals für deine Mühe!

Meines Wissens gibt es in diesem Forum bisher keinen Guide für die Sicherung der eigenen DRV! Dabei sollte es in meinen Augen zum Handwerkzeug eines jeden Tuners gehören, ein eigenes Backup von seinem Controller / DRV erstellen zu können, um dieses dann im Notfall wieder einspielen zu können. Damit muss man dann auch nicht mehr auf zweilichtige Tools zurückgreifen, um den Originalzustand wiederherzustellen. Und wenn ich es richtig verstanden habe, ist es auch viel unkomplizierter (kein Fehler, kein gepiepe, keine Aktivierung notwendig).

 

[Gerhard]

Gute Arbeit, vielen Dank! Hab' ich im Auge für einen "Pin" die Tage

 

[Daniel_Gee]

Update;

Zum Theam "Größe der DRV" möchte ich noch etwas hinzufügen. Ich hatte das auf dem Radar aber zwecks der Einfachheit nicht erwähnt.
Ich habe die Größe der recover_DRV.bin etwas großzügig angegeben und das hatte einen Grund;

# als zweites die recover_DRV.bin erstellen, kann natürlich auch eine VLT sein
>> dump_image recover_DRV.bin 0x08001000 0x00006FFF

Ich habe die DRV 223/236/247, was die Größe angeht, verglichen und festgestellt, dass es Unterschiede gibt.
Um mein Projet so einfach wie möglich zu halten, habe ich als Referenz die DRV247 genommen und habe noch ein paar Byte's drauf gepackt;

0x00006FFF

Wenn ihr die DRV als recover_DRV.bin abgespeichert habt, dann prüft bitte diese mit dem HexEditor. Am Ende der Datei dürften dann ein paar 'FF' kommen, welche ihr dann natürlich löschen könnt.

VooDooShamane hat mir hierfür folgendes mit auf den Weg gegeben;

DRV236
28660 Bytes = 6FF4 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006FF4

DRV247
28276 Bytes = 6E74 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006E74

Grund für eine genaue Größe ist die md5 Summe, welcher der VLT_Zipper von VooDooShamane prüft und auch wichtig ist. Viele Wege führen nach Rom. Ich verwende von nandtek das Script zip.py um mir meine .bin zu zippen und daher hatte ich das mit der md5 Summe nicht auf dem Schirm, sorry.

Das Projet ist Open Source und absolut individuell; weshalb ja auch „Dea Dia“, Wachstum!

 

[Dogmata]

Warum ich das Projekt XiaoDeaDia genannt habe ist schnell erklärt; „Xiao“ dürfte jedem ein Begriff sein

Genau deshalb hätte ich das nie so genannt weil ein Großteil da auch eher negativ drüber denkt ansonsten natürlich top das du dir die Mühe machst sehr gut geworden 👍

 

[Daniel_Gee]

Update;

Zum Theam "Größe der DRV" möchte ich noch etwas hinzufügen. Ich hatte das auf dem Radar aber zwecks der Einfachheit nicht erwähnt.
Ich habe die Größe der recover_DRV.bin etwas großzügig angegeben und das hatte einen Grund;

# als zweites die recover_DRV.bin erstellen, kann natürlich auch eine VLT sein
>> dump_image recover_DRV.bin 0x08001000 0x00006FFF

Ich habe die DRV 223/236/247, was die Größe angeht, verglichen und festgestellt, dass es Unterschiede gibt.
Um mein Projet so einfach wie möglich zu halten, habe ich als Referenz die DRV247 genommen und habe noch ein paar Byte's drauf gepackt;

0x00006FFF

Wenn ihr die DRV als recover_DRV.bin abgespeichert habt, dann prüft bitte diese mit dem HexEditor. Am Ende der Datei dürften dann ein paar 'FF' kommen, welche ihr dann natürlich löschen könnt.

VooDooShamane hat mir hierfür folgendes mit auf den Weg gegeben;

DRV236
28660 Bytes = 6FF4 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006FF4

DRV247
28276 Bytes = 6E74 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006E74

Grund für eine genaue Größe ist die md5 Summe, welcher der VLT_Zipper von VooDooShamane prüft und auch wichtig ist. Viele Wege führen nach Rom. Ich verwende von nandtek das Script zip.py um mir meine .bin zu zippen und daher hatte ich das mit der md5 Summe nicht auf dem Schirm, sorry.

Das Projet ist Open Source und absolut individuell; weshalb ja auch „Dea Dia“, Wachstum!

Was ich ganz vergessen habe, sorry, mein Projekt funktioniert natürlich auch mit dem 1s auch wenn ich die dafür notwendigen DRV's nicht erwähnt habe.
Es funktioniert mit alles Controller welche den STM32 Chip verwenden, nur muss hier natürlich die Adressen noch zusätzlich angepasst und geprüft werden. ✌️👍

Ergänzung: ( 16 März 2022 )

Genau deshalb hätte ich das nie so genannt weil ein Großteil da auch eher negativ drüber denkt ansonsten natürlich top das du dir die Mühe machst sehr gut geworden 👍

Danke für deinen Hinweis;

Es geht hier primär um den Inhalt und nicht um die von mir gewählte Namensgebung, dass zum ersten.
Zum zweiten darf dies jeder in seiner persönlichen Wahrnehmung so verstehen wie er es nun möchte.

Danke auch für deinen Zuspruch für meine Arbeit. 👍

 

[mhdot]

Zum zweiten darf dies jeder in seiner persönlichen Wahrnehmung so verstehen wie er es nun möchte.

Wenn ich es also als "XiaoSch...Sterbe" wahrnehme, dann ist das auch okay? 🤣🤣

Danke auch für deinen Zuspruch für meine Arbeit. 👍

Danke für dieses tolle Tutorial!

 

[Daniel_Gee]

Wenn ich es also als "XiaoSch...Sterbe" wahrnehme, dann ist das auch okay? 🤣🤣

Absolut 👍👌

Danke für dieses tolle Tutorial!

Gerne......bitte auch mal testen, gell 😎

 

[Daniel_Gee]

Hallo zusammen,

hat es schon jemand von euch auf die von mir vorgeschlagenen Weise durchgeführt?

 

[Olli_69]

Hallo zusammen,

hat es schon jemand von euch auf die von mir vorgeschlagenen Weise durchgeführt?

Wenn eine windoof Anleitung kommt, gerne. Klingt wesentlich einfacher als eine vlt zu patchen (mit eigenen Werten) (insider.exe off)

 

[Daniel_Gee]

Wenn eine windoof Anleitung kommt, gerne. Klingt wesentlich einfacher als eine vlt zu patchen (mit eigenen Werten) (insider.exe off)

Das freut mich. Wie du weißt arbeite ich tatsächlich snur mit Linux und habe 2005 zuletzt mit Windows gearbeitet aber ich bin dabei und werde es zeitnah veröffentlichen.

Gruß, Daniel

 

[Olli_69]

Evtl reicht es mir schon, wenn du die ersten beiden Schritte "ubersetzt"... Drr erste bedeutet openocd zu installieren und zu starten?

Der zweite benötigt nur einen telnet-client?

In dem erfolgen dann alke weiteren Aktionen?

Wofür dann genau openocd?

 

[Daniel_Gee]

Evtl reicht es mir schon, wenn du die ersten beiden Schritte "ubersetzt"... Drr erste bedeutet openocd zu installieren und zu starten?

Der zweite benötigt nur einen telnet-client?

In dem erfolgen dann alke weiteren Aktionen?

Wofür dann genau openocd?

Beide hängen zusammen. OpenOCD stellt die Verbindung über den ST Link mit dem STM32 her und mit telnet kommuniziert man.
Unter Windows muss man den telnet-Client aktivieren, dass kann ich dir morgen per Screenshot schicken. OpenOCD musst downloaden und dort liegt dann die ausführbare .exe welche du benötigst.
Wie gesagt, ich mache das noch für Windows aber dazu benötige ich tatsächlich noch etwas Zeit.

Gruß,
Daniel

 

[Olli_69]

Alles gut, so hatte ich es auch gedacht. Den Rest kriege ich hin, Windows und telnet-client sind MEIN Ding 😉

 

[Daniel_Gee]

Alles gut, so hatte ich es auch gedacht. Den Rest kriege ich hin, Windows und telnet-client sind MEIN Ding 😉

Die Befehle müssten auch die gleichen sein, werden ja auch auf der gleichen Plattform ausgeführt. Das Betriebssystem ist nebensächlich. Wie auch bei Python, Python ist Python ob jetzt für Linux oder Windows.

Dann kannst ja das mal testen und das Ergebnis hier veröffentlichen, wäre dankbar wenn das jemand mit Windows macht.

Hast du einen St Link zur Hand?
Wollte dir ne PN schicken aber das geht wohl nicht.

Gruß, Daniel

 

[Olli_69]

Alles da, hab vor ca. 2 Jahren schon controller/dash ge-st-linked, ist aber nach einiger Zeit ruhiger geworden, dann nur noch zum testen

Ergänzung: ( 18 März 2022 )

PN hab ich gesperrt, zu viele Anfragen von Neulingen 😅

 

[Daniel_Gee]

Alles da, hab vor ca. 2 Jahren schon controller/dash ge-st-linked, ist aber nach einiger Zeit ruhiger geworden, dann nur noch zum testen

Ergänzung: ( 18 März 2022 )

PN hab ich gesperrt, zu viele Anfragen von Neulingen 😅

Ja super, dann könntest ja du den Guide für Windows schreiben, sofern du Interesse hast.
Der Vorteil von meiner Vorgehensweise ist, dass du ja ein komplettes Backup erstellen kannst und dieses auch wieder flashen.
Hab ein ESC und ein Dashboard an mein Labormessgerät gehängt, quasi als Teststation.
Über die von mir vorgestellten Methode möchte ich mein BMS reaktivieren und diesbezüglich ein Thread eröffnen. Bräuchte dann wieder jemand für Windows 👍

 

[VooDooShamane]

Daniel_Gee
Glückwunsch zum Content creator Rang hier im RP

---

Ich finde den Guide wirklich gelungen!
Mir ist dennoch eine Kleinigkeit aufgefallen.
Damit will ich keinenfalls deinen Guide in irgend einer Art schlecht machen!

Es ist ja so, das die Vanilla DRV's häufig durch dirverse Tools auf md5 Summen validität geprüft werden.
Ist ja bekannt aus der info.txt die immer in den Zip files liegt.
Aus diesem Grund würde ich es toll finden, wenn in dem Guide die DRV versions-Größe berücksichtigt wird.
Damit nach einem erfolgreichen Dump, auch die md5 Summe stimmt.
Weil diese Vanilla DRV dumps könnten ja dann z.b. für das erstellen einer VLT weiter verarbeitet werden.
Hier habe ich eine Auflistung für die jeweilige DRV Version:
(hab ich Daniel_Gee schon per PN geschickt, nur scheinen 2 DRV übersehen worden sein)

👆🏻 Spoiler: DRV236

28660 Bytes = 6FF4 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006FF4

👆🏻 Spoiler: DRV304

28644 Bytes = 6FE4 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006FE4

👆🏻 Spoiler: DRV247

28276 Bytes = 6E74 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006E74

👆🏻 Spoiler: DRV319

28148 Bytes = 6DF4 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00006DF4

Falls man den Kompletten für DRV reservierten (app) part von dem stm32f1x MCU zu ziehen möchte,
Sieht man in diesem Bild.
Der app teil ist der Bereich der für die DRV reserviert ist.
Der startet bei 08001000
Der nächste Teil (update) startet bei 08008400

08008400 - 08001000 = 7400 Hex

👆🏻 Spoiler: FullDRV

29696 Bytes = 7400 Hexadezimal
Befehl zum dumpen : dump_image recover_DRV.bin 0x08001000 0x00007400

 

[Daniel_Gee]

Guten Morgen VooDooShamane,

danke für deinen sehr ausführlichen Guide und die damit verbundene Mühe welche du dir gemacht hast.
Auch dein Aufbau werde ich mir als Vorbild nehmen, sehr schön gemacht und auch sehr übersichtlich.

Nach deiner PN über die Möglichkeit "only OpenOCD" habe diese auch geprüft und durchgeführt, klappt super.
Nur habe ich mich aus folgenden Gründen dagegen entschieden, diese in den Guide mit einzubringen;

-> Ich wollte bewusst, dass der Anwender die Befehle einzeln eingeben muss, damit die Möglichkeit gegeben ist, dass er diese Befehle auch versteht.

-> openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "stm32f1x unlock 0" -c "flash write_image erase unlock recover_ESC.bin 0x08000000 bin"

Dieser Befehl ist sehr lang und wird sehr wahrscheinlich per "copy & past" ausgeführt, was ich vermeinden wollte. Zudem kann man mit telnet im Anschluss nach dem erstellen einer recover_ESC eine recover_DRV erstellen ohne gleich wieder so einen langen Befehl eingeben zu müssen.

-> Die Größe der DRV ist ja quasi variable und es werden ja auch neue DRV's raus kommen. Mit meinem Vorgehen ist der Anwender quasi gezwungen mal in die .bin Datei zu schauen um diese zu prüfen, was in meinen Augen wiederum ein Lerneffekt mit sich bringt.

Natürlich habe ich eine andere Methodik und Didaktik als andere und bin, nun ja, ein Freund der einzelnen Befehle in der CLI, denn dadurch habe ich 2005 Linux kennen und lieben gelernt. Sicherlich habe ich sehr viel von meinen Vorgehen mit einfließen lassen aber wie gesagt, ich wollte das der Anwender was lernen kann und zwar ohne "copy & past".

Das folgende von dir ist wirklich MEGA. Danke nochmals für diesen wertvollen Beitrag;

Desweiteren gibt es eine Möglichkeit openOCD ohne telnet zu nutzen.
Siehe z.b.

Bitte verwende, Anmelden oder Registrieren zum Anzeigen von URL-Inhalten!

Macht die ganze Sache in meinen Augen etwas einfacher und übersichtlicher.
Windows Binnaries von OpenOCD können z.b. aus dem Git Repo von CamiAlfa

Bitte verwende, Anmelden oder Registrieren zum Anzeigen von URL-Inhalten!

herunter geladen werden.

Dieser Command erstellt einen full-Dump des Flash speichers. Direkt und ohne Umweg über telnet.
-c ist ein "chaining Parameter", der ermöglicht alles in einem Befehl zu machen.
Dieser Command ist immer der selbe, egal ob Windows oder Linux.
(Bei Linux müsste ggf. noch sudo davor geschrieben werden)

Bitte verwende, Anmelden oder Registrieren um den Inhalt der Codes anzuzeigen!

In dem full-Dump sind alle in dem obigen Bild zu sehende Bereiche des Flash speichers enthalten.

• Bootloader Offset 0x08000000 bis 0x08001000
• App (DRV) Offset 0x08001000 bis 0x08008400
• Update (DRV) Offset 0x08008400 bis 0x0800F800
• App_Config Offset 0x0800F800 bis 0x0800FC00
• Upd_Config Offset 0x0800FC00 bis 0x08020000 (Ende Flash-Speicher)

Wünsche allen ein schönes Wochenende.

Gruß, Daniel