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

[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

Post automatically merged: 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

Post automatically merged: 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.

Um Links zu sehen, melde dich bitte an

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

Um Links zu sehen, melde dich bitte an

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)

openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "stm32f1x unlock 0" -c "dump_image recover_ESC.bin 0x08000000 0x00020000"

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