STM32L4 erase / write error

[STM32L4 (Gast)]

Hallo,

ich habe ein Problem mit einem STM32L431KB, bin allerdings Neuling in 
Bezug auf STM.

Der uC ist neu und wird prinzipiell vom ST-Link-Utility / 
STM32CubeProgrammer erkannt (Device, Typ, ID, Flash Size, CPU, Target 
Vdd, ...)

Allerdings lässt er sich nicht programmieren. Nach einigen Versuchen mit 
dem ST-Link Utility bin ich auf den STM32CubeProgrammer gewechselt.

Folgendes Fehlerbild: Der uC lässt sich nicht löschen (weder gesamt nich 
einzelne Sektoren), noch beschreiben. Auch die Option Bytes lassen sich 
nicht manipulieren.

Dazu folgende Ausgaben vom CubeProgrammer:

Beim Versuch, dass .elf-File zu flashen wird folgendes gelogt:

15:18:57:180 : Memory Programming ...
15:18:57:181 : Opening and parsing file: Test.elf
15:18:57:182 : File : Test.elf
15:18:57:182 : Size : 864 Bytes
15:18:57:183 : Address : 0x08000000
15:18:57:183 : Erasing Segment <0> Address <0x08000000> Size <864>Bytes
15:18:57:183 : Erasing memory corresponding to segment 0:
15:18:57:183 : Memory erase...
15:18:57:186 : reset ap 0
15:18:57:186 : halt ap 0
15:18:57:186 : w ap 0 reg 15 (0x20000000)
15:18:57:188 : w ap 0 reg 17 (0x20000500)
15:18:57:188 : w ap 0 reg 16 (0x01000000)
15:18:57:195 : w ap 0 @0x20000D00 0x00000200 bytes
15:18:57:195 : w ap 0 @0x20000000 0x00000004 bytes
15:18:57:220 : w ap 0 @0x20000004 0x000008C8 bytes
15:18:57:221 : Erasing internal memory sector 0
15:18:57:221 : Init flashloader...
15:18:57:221 : halt ap 0
15:18:57:221 : w ap 0 reg 0 0x00000001
15:18:57:222 : w ap 0 reg 1 0x00000000
15:18:57:222 : w ap 0 reg 2 0x00000000
15:18:57:222 : w ap 0 reg 3 0x00000000
15:18:57:222 : w ap 0 reg 4 0x00000000
15:18:57:222 : w ap 0 reg 5 0x00000000
15:18:57:222 : w ap 0 reg 6 0x00000000
15:18:57:222 : w ap 0 reg 7 0x00000000
15:18:57:222 : w ap 0 reg 8 0x00000000
15:18:57:227 : w ap 0 reg 9 0x00000000
15:18:57:234 : w ap 0 reg 10 0x00000000
15:18:57:237 : w ap 0 reg 11 0x00000000
15:18:57:237 : w ap 0 reg 12 0x00000000
15:18:57:239 : w ap 0 reg 13 0x00000000
15:18:57:239 : w ap 0 reg 14 0x20000001
15:18:57:239 : w ap 0 reg 15 0x20000005
15:18:57:239 : w ap 0 reg 16 0x01000000
15:18:57:241 : w ap 0 reg 17 0x20000CC8
15:18:57:241 : w ap 0 reg 18 0x00000000
15:18:57:241 : run ap 0
15:19:02:004 : halt ap 0
15:19:02:004 : Init function fail with timeout
15:19:02:004 : r ap 0 reg 16 0x81000000
15:19:02:004 : Loader sector erase...
15:19:02:004 : Error: failed to erase memory
15:19:02:037 : Error: failed to erase memory

Aktiviere ich die Option "Skip flash erase before programming", dann 
wird folgendes ausgegeben:

15:19:19:733 : Memory Programming ...
15:19:19:733 : Opening and parsing file: Test.elf
15:19:19:734 : File : Test.elf
15:19:19:735 : Size : 864 Bytes
15:19:19:735 : Address : 0x08000000
15:19:19:735 : Download in Progress:
15:19:19:735 : Size : 864 Bytes
15:19:19:735 : Address : 0x08000000
15:19:19:736 : Buffer program...
15:19:19:741 : reset ap 0
15:19:19:741 : halt ap 0
15:19:19:741 : w ap 0 reg 15 (0x20000000)
15:19:19:742 : w ap 0 reg 17 (0x20000500)
15:19:19:742 : w ap 0 reg 16 (0x01000000)
15:19:19:747 : w ap 0 @0x20000D00 0x00000200 bytes
15:19:19:747 : w ap 0 @0x20000000 0x00000004 bytes
15:19:19:764 : w ap 0 @0x20000004 0x000008C8 bytes
15:19:19:765 : Loader write range...
15:19:19:771 : w ap 0 @0x20000D00 0x000001B0 bytes
15:19:19:771 : W B1 in RAM @0x20000D00 size 0x000001B0 : 0004ms
15:19:19:771 : Init flashloader...
15:19:19:771 : halt ap 0
15:19:19:772 : w ap 0 reg 0 0x00000001
15:19:19:772 : w ap 0 reg 1 0x00000000
15:19:19:774 : w ap 0 reg 2 0x00000000
15:19:19:779 : w ap 0 reg 3 0x00000000
15:19:19:779 : w ap 0 reg 4 0x00000000
15:19:19:779 : w ap 0 reg 5 0x00000000
15:19:19:779 : w ap 0 reg 6 0x00000000
15:19:19:780 : w ap 0 reg 7 0x00000000
15:19:19:780 : w ap 0 reg 8 0x00000000
15:19:19:780 : w ap 0 reg 9 0x00000000
15:19:19:780 : w ap 0 reg 10 0x00000000
15:19:19:780 : w ap 0 reg 11 0x00000000
15:19:19:781 : w ap 0 reg 12 0x00000000
15:19:19:781 : w ap 0 reg 13 0x00000000
15:19:19:786 : w ap 0 reg 14 0x20000001
15:19:19:786 : w ap 0 reg 15 0x20000005
15:19:19:790 : w ap 0 reg 16 0x01000000
15:19:19:797 : w ap 0 reg 17 0x20000CC8
15:19:19:797 : w ap 0 reg 18 0x00000000
15:19:19:797 : run ap 0
15:19:24:000 : halt ap 0
15:19:24:000 : Init function fail with timeout
15:19:24:004 : r ap 0 reg 16 0x41000000
15:19:24:004 : w ap 0 @0x20000EB0 0x000001B0 bytes
15:19:24:004 : W B2 in RAM @0x20006500 size 0x000001B0: 4236ms
15:19:24:010 : r ap 0 reg 0 0x48000000
15:19:24:012 : reset ap 0
15:19:24:012 : halt ap 0
15:19:24:012 : w ap 0 reg 15 (0x20000000)
15:19:24:014 : w ap 0 reg 17 (0x20000500)
15:19:24:014 : w ap 0 reg 16 (0x01000000)
15:19:24:020 : Loader write range...
15:19:24:026 : w ap 0 @0x20000D00 0x000001B0 bytes
15:19:24:026 : W B1 in RAM @0x20000D00 size 0x000001B0 : 0004ms
15:19:24:027 : halt ap 0
15:19:24:027 : r ap 0 reg 0 0x00000000
15:19:24:027 : Error: failed to download Segment[0]
15:19:24:027 : Error: failed to download the File
15:19:24:048 : Time elapsed during download operation: 00:00:04.284
15:19:24:048 : Verifying ...
15:19:24:048 : Read progress:
15:19:24:049 : Reading data...
15:19:24:053 : r ap 0 @0x08000000 0x00000360 bytes
15:19:24:054 : Error: Data mismatch found at address 0x08000000 (byte = 0xFF)
15:19:24:054 : Error: Download verification failed

Auch die "Option Bytes" kann ich nicht ändern, testweise am BOR-Level 
probiert:

15:21:44:241 : Option byte command : -ob BOR_LEV=4
15:21:44:244 : PROGRAMMING OPTION BYTES AREA ...
15:21:44:244 : r ap 0 @0x40022040 0x00000004 bytes
15:21:44:244 : Bank : 0x00
15:21:44:244 : Address : 0x40022020
15:21:44:244 : Size : 20 Bytes
15:21:44:296 : Buffer program...
15:21:44:301 : reset ap 0
15:21:44:301 : halt ap 0
15:21:44:301 : w ap 0 reg 15 (0x20000000)
15:21:44:302 : w ap 0 reg 17 (0x20000500)
15:21:44:302 : w ap 0 reg 16 (0x01000000)
15:21:44:308 : w ap 0 @0x20000D00 0x00000200 bytes
15:21:44:309 : w ap 0 @0x20000000 0x00000004 bytes
15:21:44:327 : w ap 0 @0x20000004 0x000008C8 bytes
15:21:44:329 : w ap 0 @0x20000D00 0x00000014 bytes
15:21:44:330 : Loader write option bytes...
15:21:44:330 : Init flashloader...
15:21:44:330 : halt ap 0
15:21:44:334 : w ap 0 reg 0 0x00000001
15:21:44:334 : w ap 0 reg 1 0x00000000
15:21:44:334 : w ap 0 reg 2 0x00000000
15:21:44:335 : w ap 0 reg 3 0x00000000
15:21:44:335 : w ap 0 reg 4 0x00000000
15:21:44:335 : w ap 0 reg 5 0x00000000
15:21:44:337 : w ap 0 reg 6 0x00000000
15:21:44:342 : w ap 0 reg 7 0x00000000
15:21:44:342 : w ap 0 reg 8 0x00000000
15:21:44:342 : w ap 0 reg 9 0x00000000
15:21:44:342 : w ap 0 reg 10 0x00000000
15:21:44:342 : w ap 0 reg 11 0x00000000
15:21:44:344 : w ap 0 reg 12 0x00000000
15:21:44:344 : w ap 0 reg 13 0x00000000
15:21:44:344 : w ap 0 reg 14 0x20000001
15:21:44:344 : w ap 0 reg 15 0x20000005
15:21:44:344 : w ap 0 reg 16 0x01000000
15:21:44:344 : w ap 0 reg 17 0x20000CC8
15:21:44:344 : w ap 0 reg 18 0x00000000
15:21:44:345 : run ap 0
15:21:49:000 : halt ap 0
15:21:49:000 : Init function fail with timeout
15:21:49:003 : r ap 0 reg 16 0x81005800
15:21:49:003 : WriteOB function terminated with connection error due to OB_Launch
15:21:49:003 : Reconnecting...
15:21:50:103 : STLinkUSBDriver.dll loaded
15:21:50:103 : ST-LINK SN : 066BFF504955857567125335
15:21:50:104 : ST-LINK FW : V2J33M25
15:21:50:111 : Voltage : 3.05V
15:21:50:115 : SWD freq : 4000 KHz
15:21:50:115 : Connect mode: Normal
15:21:50:115 : Reset mode : Hardware reset
15:21:50:167 : Device ID : 0x435
15:21:50:168 : Reconnected !
15:21:50:168 : Success with Time elapsed during Reconnect: 66 ms
15:21:50:223 : UPLOADING OPTION BYTES DATA ...
15:21:50:223 : Bank : 0x00
15:21:50:224 : Address : 0x40022020
15:21:50:225 : Size : 20 Bytes
15:21:50:225 : Reading data...
15:21:50:228 : r ap 0 @0x40022020 0x00000014 bytes
15:21:50:228 : OPTION BYTE PROGRAMMING VERIFICATION:
15:21:50:228 : Error: Expected value for Option Byte "BOR_LEV": 0x4, found: 0x0
15:21:50:254 : Error: Option Byte Programming failed
15:21:50:328 : Option byte refresh
15:21:50:399 : UPLOADING OPTION BYTES DATA ...
15:21:50:400 : Bank : 0x00
15:21:50:400 : Address : 0x40022020
15:21:50:400 : Size : 20 Bytes
15:21:50:400 : Reading data...
15:21:50:400 : r ap 0 @0x40022020 0x00000014 bytes

Die Option Bytes werden wie im Anhang ausgelesen. Hier habe ich nichts 
geändert (bis auf den fehlgeschlagenen BOR-Test), weiß aber nicht, ob 
die Einstellungen so richtig sind.

An Hardware nutze ich den ST-Link/V2-1 eines Nucleo Boards (Firmware 
wurde aktualisiert).
Der STM selbst ist lediglich mit den Vdd/Vref + Block-Cs beschaltet 
sowie 4 Leitungen zum SWD-Port (SWDIO, SWCLK, nRST, GND)

Hat jemand einen Tipp was ich falsch mache...

[A. B. (Gast)]

Der Inhalt der Option-Bytes im Bild oben ist der ausgelesene Zustand? 
Der sieht problemlos aus.

Da die Kommunikation mit ST-Link und Target ja offenbar (zumindest 
anfangs) klappt, wird es wohl eher ein Hardware-Problem sein:

Abblockkondensatoren, Versorgungsspannung, SWD-Takt zu hoch, Leitungen 
zu lang ...
Wobei ich auf die Versorgung tippen würde. Fürs Programmieren und 
Löschen zieht die Ladungspumpe beim Einschalten der "Hochspannung" u. U. 
kurzzeitig kräftig Strom. Wenn dann der "Saft" nicht reicht ...

Ansonsten fällt mir nur eine eher ausgefallene Möglichkeit ein: In den 
Option-Bytes gibt's ein paar "reservierte" Bits, die u. U. irgendwelche 
undokumentierte Funktionen haben. Wenn da etwas durcheinander gekommen 
ist ... Normalerweise sollte man da mit den ST-Tools keinen Unfug 
anrichten können, aber einen H7 hat mir das ST-Link-Utility schon mal 
zerschossen.
Die Reparatur war etwas umständlich (manuell in den Flash-Registern 
herumstochern). Zur Sicherheit Inhalt der Option-Bytes (ab 0x1FFF7800, 
nicht in den Flash-Registern!!!) mit "ST production value" lt. RM 
vergleichen.

Wenn das ein "frischer" Chip war und es gleich beim ersten Versuch 
Schwierigkeiten gab, scheidet das Problem mit den Option-Bytes 
allerdings wohl aus.

Schlichtweg "kaputt" wär' natürlich auch nicht ausgeschlossen, aber doch 
ziemlich unwahrscheinlich.

[pegel (Gast)]

Es scheint ja einmal geklappt zu haben.
Du hast nicht zufällig SWD in deiner Test.elf abgeschaltet?

[STM32L4 (Gast)]

A. B. schrieb:
> Der Inhalt der Option-Bytes im Bild oben ist der ausgelesene
> Zustand?
Ja

> Abblockkondensatoren,
10µ + je 100n pro Vdd-Pin

> Versorgungsspannung,
3V3

> SWD-Takt zu hoch,
getestet mit 4, 2, 0,95 und 0,1 Mhz - immer das gleiche

> Leitungen zu lang ...
~ 20 cm

> Wobei ich auf die Versorgung tippen würde. Fürs Programmieren und
> Löschen zieht die Ladungspumpe beim Einschalten der "Hochspannung" u. U.
> kurzzeitig kräftig Strom. Wenn dann der "Saft" nicht reicht ...
werde ich mal prüfen

> Wenn das ein "frischer" Chip war und es gleich beim ersten Versuch
> Schwierigkeiten gab,
ja

> Schlichtweg "kaputt" wär' natürlich auch nicht ausgeschlossen, aber doch
> ziemlich unwahrscheinlich.
Ich werde als letzten SChritt versuchsweise den uC tauschen


pegel schrieb:
> Es scheint ja einmal geklappt zu haben.
Eigentlich nicht, zumindest kamen immer Fehlermeldungen

> Du hast nicht zufällig SWD in deiner Test.elf abgeschaltet?
Das ist ein einfaches LED-Blinki, ich wüsste nicht wie oder wo.

[STM32L4 (Gast)]

---------------------------------
Update:
Ich habe eine zweite Platine aufgebaut (mit kürzesten Kabeln), diese 
funktionierte auf Anhieb.

Dann den ersten uC nochmal mit kürzeren Kabeln getestet, funktioniert 
auch.

Insofern herzlichen Danke für die Hilfe!
(Auch wenn ich trozdem noch verwundert bin, dass die grundlegende 
Kommunikation (uC erkennen) funktionierte ...)

[Bauform B. (bauformb)]

STM32L4 schrieb:
>> Leitungen zu lang ...
> ~ 20 cm

> Dann den ersten uC nochmal mit kürzeren Kabeln getestet,
> funktioniert auch.

Aber was war wirklich der Fehler? 20cm sollte doch kein Problem sein? 
Würde man den Unterschied zwischen einem Flachkabel und 4 bis 6 
einzelnen Adern merken?

[STM32L4 (Gast)]

scheinbar schon..

[A. B. (Gast)]

> (Auch wenn ich trozdem noch verwundert bin, dass die grundlegende
> Kommunikation (uC erkennen) funktionierte ...)

Wenn nur so alle 10.000 Bits mal eins falsch ankommt, reicht das schon.
Allerdings wundere ich mich schon, dass es bei 20cm solche Probleme 
gibt.
Bei mir werkelt gerade ein ST-Link V3 mit 24 MHz SWD-Takt ebenfalls über 
ca. 20cm "fliegende" Verdrahtung an einem Nucleo-F767, hunderte Mbytes 
ohne jedes Problem ...

An den 20cm allein liegt's deshalb ganz sicher nicht, irgendwo sind die 
Randbedingungen wohl in dem speziellen Fall besonders ungünstig.