Stlink: Der Versuch, auf STM32L052K8 zu flashen, beschädigt den Flash-Speicher

Das ist ein seltsames Problem, ich konnte nicht sofort sagen, was das Problem verursacht. Ich denke, der L1-Loader ist mit den L0-Chips kompatibel, da sie fast gleich sind.

Es scheint ein wenig seltsam - lassen Sie mich wissen, ob es Debug-Flags oder etwas gibt, das ich aktivieren sollte, um weitere Informationen bereitzustellen.

Versuchen Sie, eine flache Binärdatei mit st-flash zu flashen, anstatt mit einem Elf.

Versuchen Sie, den Flash in eine Datei zurückzulesen und zu vergleichen, oder untersuchen Sie ihn mit gdb oder Beispiel
x/32x 0x8000000

Sie sollten den Anfang Ihrer Vektortabelle sehen...
Woher kommt Ihre Binärdatei und woher wissen Sie, dass sie gut ist?

Auch wenn Ihre Adresse im RAM zu sein scheint, wie ist der Status Ihres BOOT-Pins?

Ich werde einen Blick darauf werfen - ich wollte sowieso lernen, wie man .bin-Dateien flasht, anstatt .elfs mit einem Debugger hochzuladen.

Der Code war eines der Beispiele von ST, aber ich werde mir noch einmal ansehen, wo sich die Vektortabelle befindet.

Der BOOT0-Pin wird auf Masse gezogen, daher denke ich nicht, dass er in den RAM booten sollte.

Ich werde diese Fragen innerhalb von ein oder zwei Tagen beantworten - danke für die Ratschläge!

Okay, ich habe versucht, das L0-Testprogramm (insbesondere das LSI-Initialisierungsbeispiel von ST) auf ein L031K6 Nucleo-32-Board zu flashen, und das funktioniert gut.

Beim L051K8 beobachte ich das Problem jedoch immer noch. Der Hauptunterschied besteht darin, dass ich einen generischen USB-Dongle verwende, um das L051K8-Board und den integrierten ST-Link/V2-1-Debugger für das L031K6 Nucleo-Board zu programmieren. Ich habe versucht, die Firmware des USB-Debuggers zu aktualisieren, aber das hat nicht geholfen.

Ich habe überprüft, dass die Vektortabelle in beiden Fällen mit arm-eabi-none-nm richtig platziert ist: 08000000 R g_pfnVectors

Das Flashen einer .bin-Datei auf den L051K8 mit st-flash write main.bin 0x08000000 löst einen Fehler aus, meldet aber dennoch Erfolg. Das anschließende Verbinden mit dem Chip zeigt jedoch, dass das Programm bei 0xFFFFFFFE hängen bleibt.

Hier ist die Ausgabe von st-flash :

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

Aber wenn ich mir den Flash-Speicher mit dem GUI-Dienstprogramm von ST anschaue, sehe ich, dass die Hex-Datei der .bin-Datei bei 0x08000000 beginnt; es sieht aus wie die Vektortabelle beim Start des Programms. Und der geschriebene Speicher sieht so aus, als ob er bei 0x080047E0 endet, was für die Größe des Programms richtig erscheint.

Ich weiß nicht - wenn dies nicht etwas ist, das andere replizieren können, vermute ich, dass es die Chips oder Boards sein könnten, die ich verwende.

Hallo,

Gleiches Problem mit Blue-Pillboard (STM32F103C8X)
Nach jedem Programm mit 'arm-none-eabi-gdb' war ich erfolgreich, das Programm lief gut im Board, aber als ich versuche, es erneut zu programmieren, bekam ich diese Probleme:

st-util

[ abdullatif@Host-001 ~]$ st-util
st-util 1.5.0
2018-05-04T23:47:27 INFO common.c: Geräteparameter laden....
2018-05-04T23:47:27 WARN common.c: Ungültiger Blitztyp, bitte Gerätedeklaration prüfen check
2018-05-04T23:47:27 INFO gdb-server.c: Chip-ID ist 00000000, Core-ID ist 00000000.
04.05.2018T23:47:27 INFO gdb-server.c: Abhören bei *:4242...
2018-05-04T23:47:40 INFO gdb-server.c: 0 HW-Breakpoint-Register gefunden
2018-05-04T23:47:40 INFO gdb-server.c: GDB verbunden.

gdb

[ abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf
GNU-gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder höher http://gnu.org/licenses/gpl.html
Dies ist freie Software: Es steht Ihnen frei, sie zu ändern und weiterzugeben.
Es besteht KEINE GEWÄHRLEISTUNG, soweit gesetzlich zulässig. Geben Sie "Kopieren anzeigen" ein
und "Garantie anzeigen" für Details.
Diese GDB wurde als "--host=x86_64-pc-linux-gnu --target=arm-none-eabi" konfiguriert.
Geben Sie "Konfiguration anzeigen" für Konfigurationsdetails ein.
Anweisungen zur Fehlerberichterstattung finden Sie unter:
http://www.gnu.org/software/gdb/bugs/ .
Das GDB-Handbuch und andere Dokumentationsressourcen finden Sie online unter:
http://www.gnu.org/software/gdb/documentation/ .
Um Hilfe zu erhalten, geben Sie "Hilfe" ein.
Geben Sie "apropos word" ein, um nach Befehlen zu suchen, die sich auf "word" beziehen...
Lesen von Symbolen aus Stm32blink.elf...fertig.
(gdb) Ziel Extended-Remote :4242
Remote-Debugging mit :4242
0x00000000 im ?? ()
(gdb) laden
Ladeabschnitt .isr_vector, Größe 0x10c lma 0x8000000
Ladevorgang gescheitert
(gdb)

Ich muss den Bootloader mit 'st-flash' flashen wenn ich was am Board wieder zum laufen bekomme.

Ich bin nicht davon überzeugt, dass das F103-Problem dasselbe ist wie das, was ich gesehen habe; es scheint von diesem Tool ziemlich gut unterstützt zu werden, und das L0-Problem tritt sogar auf einem leeren Chip auf.

Der ursprüngliche Titel dieser Ausgabe war leider falsch; das Verhalten tritt auf den folgenden beiden Geräten auf:

• STM32L052K8

• STM32L082KZ

Ich habe mir src/chipid.c angesehen und festgestellt, dass nur die Referenzhandbücher für L0x1- und L0x3-Chips für die Einstellungen referenziert wurden; Könnten L0x2-Chips größere Unterschiede aufweisen?

Das folgende Diff scheint dieses Problem für mich vollständig zu lösen (mit einem STM32L052K8), aber ich vermute, dass es keine ideale Lösung ist:

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

Diese Änderung entfernt das L0 -spezifische Verhalten für das Massenlöschen von Chips, die mit dem generischen L0x3 Label identifiziert werden, das mit der ID 0x0417 verknüpft ist.

Ich weiß nicht, warum die L0 -spezifische Logik Probleme mit diesen 'Kategorie-3' L0x2 Chips verursachen könnte; es scheint gut mit einem STM32L031 Nucleo-Board zu funktionieren, bei dem der Chip eine ID von 0x0425 die sich als Gerät der Kategorie 2 identifiziert.

Habe ähnliche Probleme mit einem STM32L151CC.
Es wirft den gleichen Fehler und schlägt beim Überprüfungsschritt fehl.
Eine manuelle Validierung des Speichers mit dem ST-Link-Dienstprogramm zeigt, dass der Flash korrekt geschrieben wurde.
Am Gerät ist kein Schreib-/Leseschutz gesetzt.

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : Bitte überprüfen Sie, ob das Problem in Release v1.5.1 noch besteht.

Sicher, gerne nachprüfen, ob dies bei STM32L0-Kategorie-2-Chips noch passiert.

Die meisten meiner Boards befinden sich jedoch im Lager, so dass ich es wahrscheinlich nicht tun kann, bis ich im Mai umgezogen bin. Das tut mir leid.

@WRansohoff : Irgendein Update dazu?

Hallo, ich habe das gleiche Problem mit STM32L433RC.
Ich verwende st-util 1.6.1

Versuchen Sie, den Flash Ihrer MCU zu löschen
Verwenden Sie diesen Artikel: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Vielleicht haben Sie vergessen, SWD /JTAG-Pins bei STM32Cube zu markieren