Ich habe ein benutzerdefiniertes Board mit einer STM32F103VE-MCU. Mit dem ST-Link-Dienstprogramm kann ich problemlos eine Verbindung herstellen, und ich hatte sogar einige Male Code darauf heruntergeladen (sowohl im ST-Link-Dienstprogramm als auch in CooCox), aber heute habe ich Probleme beim Löschen des internen Flash-Speichers der MCU.
Beim Durchführen einer Massenlöschung (Target -> Erase Chip im ST-Link-Dienstprogramm) lautet das Protokoll „Flash-Speicher gelöscht ST-Link-Adapter und sogar Neustart des Computers. Wenn ich versuche, einzelne Sektoren zu löschen (Ziel -> Sektoren löschen ... im ST-Link-Dienstprogramm), erhalte ich Folgendes im Ausgabeprotokoll, nachdem ich alle zu löschenden Sektoren ausgewählt habe:
17:55:27: Flash-Seite 0 @0x08000000 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
17:55:27: Flash-Seite 1 @0x08000800 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
17:55:28: Flash-Seite 2 @0x08001000 gelöscht.
17:55:28: Flash-Seite 3 @0x08001800 gelöscht.
17:55:28: Flash-Seite 4 @0x08002000 gelöscht.
17:55:28: Flash-Seite 5 @0x08002800 gelöscht.
17:55:28: Flash-Seite 6 @0x08003000 gelöscht.
17:55:28: Flash-Seite 7 @0x08003800 gelöscht.
17:55:29: Flash-Seite 8 @0x08004000 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
17:55:29: Flash-Seite 9 @0x08004800 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
...
17:55:33 : Flash Seite 33 @0x08010800 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
17:55:33: Flash-Seite 34 @0x08011000 wird nicht gelöscht. Überprüfen Sie den Speicherschutz.
17:55:33: Flash-Seite 35 @0x08011800 gelöscht.
17:55:33: Flash-Seite 36 @0x08012000 gelöscht.
...
17:56:07: Flash-Seite 254 @0x0807F000 gelöscht.
17:56:07: Flash-Seite 255 @0x0807F800 gelöscht.
Nur um das klarzustellen, dies ist kein Problem mit den Optionsbytes - die mit dem Speicherschutz zusammenhängenden sind alle klar ("Kein Schutz"), und tatsächlich erhalte ich beim Versuch, die Optionsbytes zu aktualisieren, eine Fehlermeldung, die besagt: "Option konnte nicht festgelegt werden Bytes! Bitte setzen Sie das Ziel zurück und versuchen Sie es erneut!"
Es stellt sich heraus, dass ich nur Code auf die erste Seite geschrieben hatte (0x0800000 - 0x080007FF) und dann auf die Seiten 8 bis 34 (0x08004000 - 0x080117FF). Die vermeintlich gelöschten Seiten waren also zunächst einmal leer.
Jetzt gibt es, wie oben gezeigt, auch ein Problem beim Löschen von Seite 1 (0x08000800 - 0x08000FFF). Ursprünglich war dies eine leere Seite, die beim Versuch eines Löschens wie oben ein erfolgreiches Löschen anzeigte, aber ich entschied mich für ein Experiment, das mich davon überzeugte, dass dies ein Hardwarefehler ist: Ich schrieb eine kleine .bin-Datei, die bei 0x08000800 begann. Die ersten paar Worte aus dieser 32-Bit-Datei sind:
0x20000808 0x08000255 0x08000251 0x08000251
0x08000251 0x08000251 0x08000251 0x00000000
0x00000000 0x00000000 0x00000000 0x08000251
...
Doch nachdem ich dies auf die ursprünglich leere Seite 1 geschrieben und aus dem Speicher zurückgelesen habe, bekomme ich Folgendes:
0xFDFFEFFF 0xFBFFFBFF 0xFFFFFFFF 0xDFFFFEFF
0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xF7FFFFFF
0xFFFDFFFF 0xFFFFFBFF 0xFFFFFFFF 0xFFFFFFFF
...
Von diesem Moment an wurde beim Versuch, Seite 1 zu löschen (über Ziel -> Sektoren löschen ...), ein Fehler auf dieser Seite gemeldet, genau wie oben gezeigt.
Vor diesem Hintergrund stellen sich mir zwei Fragen:
Ist diese MCU tatsächlich unwiderruflich gemauert? Dies ist nicht nur eine Frage des Sparens, sondern dies ist eine BGA-MCU, die reflowgelötet wurde, und das Nacharbeiten ist nicht meine Vorstellung von Spaß. Daher bin ich offen für alle Vorschläge, um zu versuchen, es zu entmauern.
Wenn dies ein Hardwarefehler ist, wie kam es dazu, damit ich versuchen kann, ihn in Zukunft zu verhindern? An dieser Stelle sollte ich erwähnen, dass diese Platine eine seltsame Stromversorgungsarchitektur hat, und aufgrund einiger falsch gelöteter Teile scheint es besonders niedrigen Spannungen ausgesetzt gewesen zu sein, die von einer Knopfzelle (CR1220) geliefert wurden, die vollständig entladen war (von 3,0 V auf 2,4 V) innerhalb weniger Stunden (normalerweise wird es über USB oder einen wiederaufladbaren Li-Ion-Akku mit Strom versorgt). Eine zweite Knopfzelle wurde eingesetzt, und als ich dieses Stromproblem erkannte, war sie bereits auf 2,7 V gesunken. Ich habe eine Theorie, dass der STM32 einige interne Schaltkreise hat, um die erforderliche Programmierspannung zu erzeugen, aber es braucht ein Minimum Spannung nicht richtig funktionierte, und möglicherweise war es einer niedrigeren Spannung ausgesetzt, die den Stromkreis überlastete und dauerhaft beschädigte.
BEARBEITEN : Es gibt ein Detail, das ich vergessen habe zu erwähnen, das meiner Meinung nach nicht die Ursache des Problems ist, aber vielleicht erwähnenswert ist: Eines der letzten Dinge, die ich getan habe, bevor die MCU gemauert wurde, war, versehentlich eine .bin-Datei zu programmieren an der falschen Adresse (0x200 hinter der korrekten Startadresse) und daher möglicherweise versucht hat, über das Ende des Flash-Speichers hinaus zu schreiben (dh in die Adressen 0x08080000-0x080801FF). Wenn jemand glaubt, dass dies letztendlich die MCU gemauert haben könnte, lassen Sie es mich bitte wissen.
Zuerst die Programmierspannung, sie ist im Datenblatt unter den Betriebsbedingungen des Speichers angegeben ( Seite 63 ):
Vprog Programmierspannung 2 - 3,6 V
Wenn ich also Ihren Vorschlag richtig gelesen habe, wurde er während der Programmierung möglicherweise nur von dieser Knopfzelle mit Strom versorgt? Das könnte in der Tat sehr, sehr schlecht sein. Der Controller zieht während des Schreibvorgangs (nur Flash) einen maximalen Strom von 7 mA. Eine kleine Knopfzelle kommt mit höheren Strömen wirklich nicht gut zurecht und ihre Spannung sowie die Kapazität sinken wahrscheinlich sehr schnell. Angesichts des Datenblatts eines CR1220 würde der Spannungsabfall bei einer vollen Batterie mindestens 0,5 V betragen, wenn Sie 7 mA daraus ziehen, also beginnt er bei etwa 2,35 V, nicht viel Headroom.
Aber ich frage mich auch, ob Ihre Schaltung jetzt in Ordnung ist - haben Sie den Strom gemessen und alle Spannungen und ihre Stabilität überprüft, wenn Sie Strom ziehen (eine Widerstandsdekade anschließen und ein wenig variieren)?
Nun eine Möglichkeit, wie Sie das Teil vielleicht retten können. Ich denke, es wird nicht funktionieren, da Sie keine Probleme haben, sich mit dem Gerät zu verbinden, aber trotzdem:
Der F103 verfügt über einen eingebauten Bootloader, auf den zugegriffen werden kann, wenn Sie den BOOT-Pin während des Einschaltens hochziehen. Sie benötigen außerdem Zugriff auf UART1, um mit dem Bootloader kommunizieren zu können. Lesen Sie Abschnitt 3.4 des Referenzhandbuchs . Eine weitere gute Ressource ist dieses Dokument .
Wenn Sie eine Verbindung herstellen können, gibt es ein Tool (STSW-MCU005STM32 und STM8 Flash Loader Demonstrator (UM0462)) von ST, das eine Schnittstelle mit dem Bootloader ermöglicht und den Chip löscht oder programmiert.
Schalten Sie einfach die Platine aus, ziehen Sie den Boot-Pin hoch, schalten Sie die Platine ein, laden Sie ein Programm mit SWD darauf, schalten Sie dann die Stromversorgung aus und ziehen Sie den Boot-Pin auf niedrig, bevor Sie sie wieder einschalten.
Das Programmieren von Flash erfordert höhere Spannungen als die, die Sie normalerweise liefern. Früher konnte man ein Gerät nur programmieren, indem man vpp extern bereitstellte. Heutzutage erzeugen CPUs diese Spannung intern aus VDD.
Das Programmieren von Flash ist ein heikler Prozess. Der Algorithmus geht ungefähr so: Messen Sie die Zeit, die das Bit benötigt, um den gewünschten Wert zurückzulesen, und programmieren Sie dann doppelt so lange weiter. Auch dies musste früher ein Programmierer implementieren, aber jetzt ist alles in die CPU integriert. Im stm führt das Programmieren mit unzureichendem vpp zu einem Timeout. Normalerweise gibt die vpp-Erzeugungsschaltung einfach ihr Bestes, stirbt aber nicht. Also ... meine Vermutung ist, dass es eine andere Ursache für den Ausfall der Flash-Hardware gibt ...
Schweineins
Arsenal