Flashing problems, mi pro2

Oh da ist er wieder, der salzige Rollerplausch User. 🤗. Hast du aber ganz gut drehen können, indem einfach den Fehlercode falsch beschrieben hast und mir jetzt irgendwas willst

Solange du nichts produktives beitragen kannst, lies doch bitte einfach still mit im Interesse aller anderen, danke.

Dann schau die Fehlercode Liste an.

Warum sollte er? Er und andere(die richtigen Cracks) wissen, was Fehler 27 bedeutet (siehe oben verlinkten Post).

Wenn du anderer Meinung bist, ist es an Dir, uns mit deiner Weisheit zu erleuchten 🙃
 
  • Hilfreich!
Reaktionen: 4Ultra
L leelt Falls die Methode über m365rec nicht zum Erfolg führt bitte über diesen inzwischen empfohlenen Weg gehen: .
 
Darüber habe ich in meinem ersten Beitrag geschrieben.
Die CamiAlpha-Version von github startet nicht einmal, sie erscheint und verschwindet wieder.
Alle Drähte sind gut angeschlossen (keine Kurzschlüsse), das ist also ein anderes Problem.
nandtek nandtek , du bist da fitter als ich - ich hatte was ähnliches bei Voodos Patcher, das DOS-Fenster öffnete sich und schloss sich wieder. Ich meine, es hing mit dem zu langen Pfadnamen zusammen, in dem der Patcher abgelegt war, bin mir aber nicht sicher, mit neuem Wind***-Konto ging es dann ... könnte das hier ähnlich sein?

Bringt es was, wenn er nicht die Batch-Datei startet, sondern ST-Link.exe mal "nackt", nur um zu gucken, ob er überhaupt ne Verbindung herstellt?
 
  • Hilfreich!
Reaktionen: VooDooShamane
L leelt Falls die Methode über m365rec nicht zum Erfolg führt bitte über diesen inzwischen empfohlenen Weg gehen: .
Ich habe HEX überprüft, es ist korrekt.
BIN ist auch richtig.
Ich habe auch CamiAlpha ausprobiert, es funktioniert nicht.
Ich habe versucht, eine Verbindung über ST-LINK UTILITY herzustellen, aber es funktioniert nicht.
Ich habe alle Verbindungen mit GD32 überprüft, indem ich mir den Schaltplan des Controllers mit STM32 angesehen habe, alles sieht gut aus.
 

Anhänge

  • 76B8F3D6-E35A-4EA1-9AF7-CC19584278BD.webp
    76B8F3D6-E35A-4EA1-9AF7-CC19584278BD.webp
    555,7 KB · Aufrufe: 78
  • 3427CCF8-B6A7-4068-A9E0-D581187E3DBE.webp
    3427CCF8-B6A7-4068-A9E0-D581187E3DBE.webp
    519,3 KB · Aufrufe: 71
  • F9B4F4F8-906D-4CC4-96A3-52908CAEBBDF.webp
    F9B4F4F8-906D-4CC4-96A3-52908CAEBBDF.webp
    284,5 KB · Aufrufe: 68
  • 4F9B55E3-F4CE-42A6-9A5A-9283C1F63B70.webp
    4F9B55E3-F4CE-42A6-9A5A-9283C1F63B70.webp
    175,4 KB · Aufrufe: 88
Du brauchst eine neue Version von openocd.
Der GD32E103CBT6 ist noch recht neu und wird mit den alten openocd Versionen nicht richtig unterstützt.
Hier Infos zu dem Mikrocontroller:

OpenOCD arbeitet schon daran diesen Mikrocontroller zu unterstützen.

Aber Achtung!
Der GD32E103CBT6 hat anscheinend einen ähnlichen Schutz wie der STM32.
Es wird der komplette Flash gelöscht!
Hier ein Auszug aus dem Datenblatt. (Quelle)
Security protection
The FMC provides a security protection function to prevent illegal code/data access to the
Flash memory. This function is useful for protecting the software/firmware from illegal users.
No protection: when setting SPC byte and its complement value to 0x5AA5, no protection
performed. The main flash and option bytes block are accessible by all operations.
Under protection: when setting SPC byte and its complement value to any value except
0x5AA5, the security protection is performed. Note that a power reset should be followed
instead of a system reset if the SPC modification has been performed while the debug module
is still connected to JTAG/SWD device. Under the security protection, the main flash can only
be accessed by user code and the first 4KB flash is under erase/program protection. In debug
mode, boot from SRAM or boot loader mode, all operations to main flash is forbidden. If a
read operation to main flash in debug mode, boot from SRAM or boot loader mode, a bus
error will be generated. If a program/erase operation to main flash in debug mode, boot from
SRAM or boot from boot loader mode, the WPERR bit in the FMC_STAT register will be set.
Option bytes block are accessible by all operations, which can be used to disable the security
protection. Back to no protection level by setting SPC byte and its complement value to
0x5AA5, then a mass erase for main flash will be perform

Bist du dir sicher L leelt das es auch eine orginal Firmware drauf ist?
Weil auf deinen Bildern steht dort Spoof 822 DRV Version 422.
Das ist eine mir total unbekannte Version.
Habe ich noch nie gesehen.
Wenn das wirklich eine original Firmware ist, dann unterscheidet die sich von den uns bekannten Firmwares.
Und wenn du dann mit OpenOCD doch schreiben kannst, dann hast du keine Firmware die darauf funktioniert!!!!

Schreibe mir bitte mal deine Seriennummer per Privater Nachricht.
Dann kann ich schauen ob ich an die Firmware dran komme.

Edit:
Habe gerade nochmal deinen ersten post gelesen.
Du hattest mit Xiaoflasher die DRV von 248 auf diese merkwürdige 822 geflasht.
Dann musst du zuerst mit Xiaoflasher wieder eine original Firmware flashen.
Erst danach kannst du wieder ganz normal mit Downg firmwares flashen.

LG
VooDoo
 
Zuletzt bearbeitet:
L leelt Vielleicht ist es am besten wenn du deinen Controller an VooDooShamane VooDooShamane schickst und er sich das direkt anschaut. Voodoo kennt sich sehr sehr gut mit der Thematik und den Tools aus und hat einen Pro2 zum Testen. Evtl könnte Voodoo so, wenn er erfolgreich ist, einen neuen Guide für Controller mit GD32 MCU erstellen.

Ansonsten ist hier nochmal der zur aktuellen OpenOCD Version (0.11) für Windows. Einfach das vorhandene OpenOCD (0.10) im Cami Flasher damit ersetzen. Falls es dann noch nicht geht und du den Source Code nicht selbst kompilieren möchtest, müsstest du auf das nächste Release warten.

Mit STLINK Utility wirst keinen Erfolg haben. Das Programm ist von ST und die werden ganz bestimmt nicht Unterstützung für ST Clone Produkte eingebaut haben...
 
Zuletzt bearbeitet:
Ansonsten ist hier nochmal der zur aktuellen OpenOCD Version (0.11) für Windows. Einfach das vorhandene OpenOCD (0.10) im Cami Flasher damit ersetzen. Falls es dann noch nicht geht und du den Source Code nicht selbst kompilieren möchtest, müsstest du auf das nächste Release warten.
Es wird nicht funktionieren, viele Dateien an verschiedenen Orten, unterschiedliche Dateipfade.
Sie müssen viele Dateien überarbeiten oder eine neue Datei auf der Grundlage von openocd v0.11.0 erstellen.
 
L leelt Jaskola Jaskola So oder so denke ich, dass man den Controller nicht mehr gerettet bekommt, weil um den wieder zu "unbricken" bräuchte man den original Bootloader der GD32 MCU (dieser wurde beim Flashen platt gemacht). Einen Dump vom GD32 Bootloader gibt es aber meines Wissens derzeit nirgendwo zum Herunterladen.

Hier auch die aktuelle Ansage von Topol dazu:
1651240712841.png
 
Guten Abend zusammen,

ich bin zwar im Bereich der E-Scooter neu, aber komme aus dem Bereich der HW Entwicklung. Das was hier zu sehen ist, sieht man auf dem Markt aktuell sehr oft. Einige STM32 Mikrocontroller sind aktuell sehr schwer bzw. gar nicht lieferbar. Auch schon vor den Corona bedingten Engpässen gab es viele Clones des STM32, da dieser sehr Leistungsstark ist und ein super Preis-Leistungsverhältnis bietet. Z.B. Hankshun HK32, Apexmic APM32, CKS32 oder auch den nun hier verwendeten GigaDevice GD32.

Vorteile dieser Clones ist, dass sie alle kompatibel, oder nur mit wenigen Anpassungen, zu dem org. STM32 sind. Die meisten lassen sich auch mit dem ST Link flashen. Der GD32F103 lässt sich mit dem STLink flashen. Der GD32E103 ist noch recht neu, weswegen hier nicht mehr Infos zu habe. (Software ist nicht meine Stärke, eher ein notwendiges Muss, daher kann ich zu der SW Anbindung nicht soviel sagen). Der GD32E ist auch noch ein wenig performanter als der STM32F102 und wahrscheinlich auch günstiger. Somit ist die Frage, auch wenn der STM32F102 wieder lieferbar ist, ob auf den STM32 zurück gegangen wird.
Nun will man die Vorteile eines Clones aber auch nutzen, d.h. der Vorteil ist, dass sich der GD32 möglichst wie der STM32 verhält, sodass Xiaomi (und auch viele die hier betroffen sind) wenige Anpassungen machen müssen. Kurz gesagt: ist das das, dass man trotz HW Anpassung die SW nicht anpassen will, weil ja auch immernoch die "alten Controller" mit STM32 auf dem Markt sind und auch Updates bekommen müssen.


Zudem muss man bei den STLinkv2 Clones auch drauf achten, dass einige keine echten STLink Clones sind, sondern manche nur einen CH340 drin haben, d.h. einen einfachen UART Adapter. Wenn irgendwelche User also was ausprobieren sollen, dann ist auch zu beachten, dass der STLink auch ein richtiger ist. Und es gibt auch STLinks, auf denen das PinOut auf dem Gehäuse falsch beschriftet ist. Hier ist also etwas Obacht geboten.


Das die STM32 wieder in ausreichenden Stückzahlen verfügbar sein werden, ist aktuell noch nicht absehbar.


Das Problem, dass der GD32 auch auslesegeschützt zu sein scheint, löst sich damit natürlich nicht.

Eine Möglichkeit den Controller (aktuell) zu reparieren wäre den Controller zu tauschen. Dazu muss man aber a.) entsprechend löten können und b.) den Controller erstmal bekommen. Danach kann er mittels STLink neu geflasht werden.

Viele Grüße
Chris