Stlink: STM32L422CB: st-flash kann das ihex-Image nicht flashen
Es wird versucht, eine kleine Hex-Datei auf einen STM32L422CB zu flashen. Die Hex-Datei ist in Ordnung, blinkt erfolgreich mit dem Dienstprogramm st-link. st-flash löscht die erste 2kb-Seite des Flash erfolgreich, schreibt aber die Hex-Datei überhaupt nicht.
- Programmierer/Kartentyp: STLink V2
- Programmer-Firmware-Version: V2.J34.S7
- Betriebssystem und Version: Windows 10
- Name des Stlink-Befehlszeilentools: st-flash v.1.6.0
- Zielchip (und ggf. Platine): STM32L422CB
Außerdem bitten wir Sie, das erkannte Problem so detailliert wie möglich zu beschreiben und, falls vorhanden, eine Debug-Ausgabe hinzuzufügen, indem Sie die folgende Vorlage verwenden:
Kommandozeilen-Ausgabe:
PS C:\Users\xxx\Documents\Code\Test> st-flash --format ihex write ./build/test.hex
st-flash 1.6.0
2020-04-12T18:28:57 INFO common.c: Loading device parameters....
2020-04-12T18:28:57 INFO common.c: Device connected is: L41x device, id 0x10006464
2020-04-12T18:28:57 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 2048 bytes
2020-04-12T18:28:57 INFO common.c: Attempting to write 592 (0x250) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-04-12T18:28:57 INFO common.c: Finished erasing 1 pages of 2048 (0x800) bytes
2020-04-12T18:28:57 INFO common.c: Starting Flash write for F2/F4/L4
2020-04-12T18:28:57 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 592
2020-04-12T18:28:57 INFO common.c: Starting verification of write complete
2020-04-12T18:28:57 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1
PS C:\Users\xxx\Documents\Code\Test>
Erwartet/Beschreibung:
Should flash the hex file without errors
lulle2007200
Alle 12 Kommentare
Wer kann sich das genauer anschauen?
Nightwalker-87
am 18. Apr. 2020
Ich schlage eine Überprüfung mit demselben Board und anderen Flash-Tools vor, damit wir bestätigen können, dass es sich nicht um ein Hardwareproblem handelt.
Die Überprüfung ist gleich zu Beginn fehlgeschlagen. Wenn es sich also nicht um ein Hardwareproblem handelt, kann es zu Problemen mit Flashloadern kommen. Leider wird die Fehlercodeprüfung in Flashloadern (wenn möglich) bei den meisten Modellen nicht angewendet. Ich würde vorschlagen, alle Registerwerte nach dem fehlgeschlagenen Flash auszudrucken, mit st-util und ( gdb oder lldb ).
chenguokai
am 25. Apr. 2020
Ich habe es mit beiden versucht, einem echten st link v2 und einer dieser billigen Kopien aus China. Es schlägt bei beiden fehl. Ich schaue mir die Register später an, wenn ich etwas mehr Zeit habe.
lulle2007200
am 27. Apr. 2020
Die von mir erwähnten "Flash-Tools" beziehen sich auf openocd oder die offiziellen Tools von ST. Sorry für den zweideutigen Ausdruck. Wenn Sie die Registerwerte überprüfen, ist es besser, den Registerwert STM32_FLASH_SR auszugeben, der sich in STM32_FLASH_REGS_BASE + 0x10 befindet. STM32_FLASH_REGS_BASE ist 0x40022000 auf STM32L4.
chenguokai
am 27. Apr. 2020
Entschuldigung, dass ich so spät antworte.
Ich habe versucht, ein paar verschiedene Hex-Dateien unterschiedlicher Größe zu flashen.
Flash ist erfolgreich, wenn das Hex mit dem st link Utility oder das entsprechende dfu mit dem st dfu Tool flasht wird, also würde ich sagen, dass es kein Hardwareproblem ist.
Hier ist, was STM32_FLASH_SR liest:
lulle2007200
am 4. Mai 2020
Der Hinweis ist, dass FLASH_SR anzeigt, dass PGSERR und PGAERR gesetzt sind, dh es gibt einige Ausrichtungsprobleme. Wenn Sie die allgemeinen Registerwerte nach einer fehlgeschlagenen Programmierung (mit gdb , info registers ohne Zurücksetzen der Platine vor dem Anschließen) bereitstellen und st-flash mit --debug starten können on, ich denke, wir werden in der Lage sein, mit Debug-Log- und Registerwerten weiter zu untersuchen.
Bearbeiten: Wäre besser, wenn Sie den STM32_FLASH_SR-Originalwert vor dem Flashen bereitstellen können.
chenguokai
am 4. Mai 2020
dies sind die Register nach fehlgeschlagenem Flash (ohne Reset verbunden).
Hier die Ausgabe mit --debug set:
log.txt
lulle2007200
am 4. Mai 2020
@lulle2007200 in der Mail, die ich erhalten habe, sagtest du, dass mit —debug es ohne Fehler blinkt. Mir ist aufgefallen, dass du es bearbeitet hast.
Gab es tatsächlich ein erfolgreiches Flashen mit eingeschaltetem Debug?
Wenn dies der Fall ist, kann es sich um ein Timing-Problem handeln, genau wie bei der f0-Serie.
Nach dem Protokoll scheinen die Dinge vor der Ausführung in Ordnung zu sein. die Universalregister enthalten Werte, die schwer zu erklären sind. Wenn r0 ganz am Anfang Null war, gibt es vielleicht Probleme mit Funktionen, die Werte in Register schreiben?
chenguokai
am 4. Mai 2020
Es hat nicht funktioniert, ich habe es vermasselt, als ich versuchte, die Ausgabe von st-flash in eine Datei umzuleiten. Es stellte sich heraus, dass es überhaupt nicht lief, aber ich hatte es geflasht, bevor ich st link utilty benutzte ...
Außerdem drücke ich aus Versehen zu und kommentiere statt kommentieren, sorry für die Verwirrung.
Ich schau morgen nochmal nach.
lulle2007200
am 5. Mai 2020
@lulle2007200 : Irgendein Update dazu?
Nightwalker-87
am 6. Juli 2020
Ich habe das irgendwie vergessen, das Leben kam mir in die Quere.
st-flash kann die bereitgestellte Hex-Datei nicht löschen und flashen.
Ich mehrere Dateien unterschiedlicher Größe, funktioniert mit keiner von ihnen. Beachten Sie, dass das Flashen mit dem offiziellen ST-Link-Dienstprogramm einwandfrei funktioniert.
Ich habe ein Protokoll der st-flash-Ausgabe und der Werte der Universalregister und STM32_FLASH_SR sowohl vor als auch nach dem Flash-Versuch angehängt.
log.txt
lulle2007200
am 6. Juli 2020
Jetzt suchen wir einen erfahrenen Entwickler, der mit der L4-Serie irgendwie vertraut ist, um die Chance auf einen Fix zu haben.
Nightwalker-87
am 8. Juli 2020
Verwandte Themen
grzegorz-kraszewski
·
9Kommentare
gorynch
·
5Kommentare
smartHarsh
·
9Kommentare
Hamid-Najafi
·
8Kommentare
purjus74
·
12Kommentare