Forum: Mikrocontroller und Digitale Elektronik STM32F0 SWD LockOut


von Tom W. (nericoh)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

auch nach längerer Suche in diesem und in anderen Foren habe ich keine 
ähnlich gelagerte Problematik finden können, darum dieser Beitrag:

Ich versuche gerade, ein Bischen was von der Peripherie eines STM32F030 
in Betrieb zu nehmen.

Hierzu nutze ich IAR EW 6.70 sowie einen IAR I-Jet der per SWD mit dem 
Target verbunden ist.

Wenn ich ein frisches IAR-Projekt aufsetze und konfiguriere (Device und 
Programmer auswählen etc.) kann ich dieses "leere" Projekt problemlos 
kompilieren und flashen.

Nachdem ich jedoch etwas Code (s. Anhang) geschrieben habe, um die 
Peripherie zu konfigurieren, kann ich zwar diesen Code ebenfalls noch 
einmal kompilieren und flashen, habe mich jedoch anschließend 
"ausgesperrt" (d.h. ich kann nicht mehr flashen). IAR meldet:

Failed to load flash loader: C:\Program Files (x86)\IAR Systems\Embedded 
Workbench 6.5\arm\config\flashloader\ST\FlashSTM32F05xxxRAM4K.out

Failed to load flash loader: C:\Program Files (x86)\IAR Systems\Embedded 
Workbench 6.5\arm\config\flashloader\ST\FlashSTM32F05xx6.flash


Ich würde gerne verstehen, wieso ich mich so von der SWD-Schnittstelle 
aussperre - hat jemand hierzu einen Hinweis?

Natürlich bin ich auch sehr daran interessiert, wie ich wieder Zugang 
zum Target bekomme. Aber hierzu werde ich wohl zunächst die Doku(s) noch 
etwas studieren müssen (die BOOT-Pins scheinen hier der Schlüssel zu 
sein), bevor ich das als Frage formuliere ;)

Beste Grüße,
Tom

von Helmut S. (helmuts)


Lesenswert?

Schau mal hier die Anleitung zum Wiederbeleben.

Beitrag "ARM STM32FR4 ST1-Link auf Discovery Board "no connect""

Vermutlich hast du Pins der Debug-Schnittstelle am Port-A 
umkonfiguriert.

von Tom W. (nericoh)


Lesenswert?

Den Beitrag hatte ich gesehen - nach meinem Verständnis ist das 
angenommene Problem bei mir aber nicht der Fall. Ich habe meinen Code 
auch extra nochmal neu geschrieben und hab dabei fast ausschließlich die 
STM32-StdPerihLib benutzt (um eben auszuschließen, dass ich 
versehentlich was Falsches in ein Register schreibe).

Das "STM32 ST-Link Utility" hilft mir leider auch nicht weiter, da ich 
nicht den ST-Link, sondern den IAR I-Jet nutze. Außerdem müsste ich dazu 
(soweit ich das gesehen habe) an einen der Uarts gehen - da komme ich 
jedoch bei einem Design recht schlecht dran :\

von uint32_t (Gast)


Lesenswert?

Tom W. schrieb:
> an einen der Uarts gehen - da komme ich
> jedoch bei einem Design recht schlecht dran

Eine Platine mit Laborfädeldahtabgriff, auf ein Stück Pappe geklebt und 
mit Platinchen mit Stiftleisten für ein FT232 Modul versehen, reicht 
doch als Labormuster zum Entwickeln? Oder kommt dein Prozessor etwa in 
einem BGA-Gehäuse?

von Gerd E. (robberknight)


Lesenswert?

Tom W. schrieb:
> Außerdem müsste ich dazu
> (soweit ich das gesehen habe) an einen der Uarts gehen - da komme ich
> jedoch bei einem Design recht schlecht dran :\

damit schon (wenn Du nicht gerade den Controller in QFN genommen hast):

http://www.reichelt.de/CLIP-6800-SW/3/index.html?&ACTION=3&LA=446&ARTICLE=63456

von Besserwisser (Gast)


Lesenswert?

Tom W. schrieb:
> ausschließlich die
> STM32-StdPerihLib benutzt

Das verhindert nicht, dass Du Unsinn in die Ports schreibst. Es macht es 
nur leichter ;-)

welches Package? QFP64, 48,32, 20?

Tom W. schrieb:
> C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\

Bist Du sicher, dass Du EWARM6.70 hast, wenn der Pfad auf 6.5 zeigt?

> FlashSTM32F05xx6
Passt das mit dem STM32F030 zusammen?

<code>
GPIO_InitTypeDef GPIOA_InitStructure;
  GPIOA_InitStructure.GPIO_Pin          = ( GPIO_Pin_5 | GPIO_Pin_6 | 
GPIO_Pin_7 );
  GPIOA_InitStructure.GPIO_Mode         =   GPIO_Mode_AF;
  GPIO_Init(GPIOB, &GPIOA_InitStructure);
</code>

Sollte hier nicht GPIOA stehen?

von Tom W. (nericoh)


Lesenswert?

Besserwisser schrieb:
> <code>
> GPIO_InitTypeDef GPIOA_InitStructure;
>   GPIOA_InitStructure.GPIO_Pin          = ( GPIO_Pin_5 | GPIO_Pin_6 |
> GPIO_Pin_7 );
>   GPIOA_InitStructure.GPIO_Mode         =   GPIO_Mode_AF;
>   GPIO_Init(GPIOB, &GPIOA_InitStructure);
> </code>
>
> Sollte hier nicht GPIOA stehen?

Völlig richtig - danke für den Hinweis!

Besserwisser schrieb:
> Bist Du sicher, dass Du EWARM6.70 hast, wenn der Pfad auf 6.5 zeigt?

War mir auch aufgefallen - der Pfad stammt vermutlich noch von einer 
älteren Installation. Die laufende Version ist aber definitiv 6.7. Es 
ist auch keine "Mischinstallation", bei der ich 6.7 über eine bestehene 
6.5-Installation installiert habe oder sowas in der Art.

uint32_t schrieb:
> Oder kommt dein Prozessor etwa in
> einem BGA-Gehäuse?

Ihr habt natürlich recht - an die Pins käme man mit etwas Gefrickel 
schon dran (nutze LQFP48). Trotzdem steht mir leider kein ST-Link zur 
Verfügung, daher komme ich an der Stelle (zumindest vorerst) nicht 
weiter. Wenn sonst nichts hilft, werde ich natürlich in den sauren Apfel 
beißen und mir einen ST-Link besorgen. Bis dahin werde ich mal den Weg 
über den BOOT-Pin versuchen. Zitat aus einer Antwort in einem anderen 
Forum, in dem ich den Fall auch geschildert habe: "BOOT0 = High at reset 
will stop broke user code from running."

Hatte mich wie gesagt noch net in die Doku bzgl. der BOOT-Pins 
eingelesen, da ich zunächst verstehen wollte, wieso ich mich überhaupt 
ausperre.

Danke soweit schonmal für eure Anregungen, ich berichte über 
Fortschritte (falls ich welche erziele). Weitere Hinweise und Anregungen 
sind natürlich sehr willkommen :)

von Tom W. (nericoh)


Lesenswert?

Falls noch jemand ein ähnliches Problem haben sollte:

-> BOOT0 muss bei Reset auf 3,3V liegen - dann wird der Usercode (der 
zur "Ausperrung" führt, nicht ausgeführt und man kann wieder flashen !

von Sascha (Gast)


Lesenswert?

Hallo,
Vorsicht ist bei den ganz neuen Derivaten geboten, da kann man sich 
durch setzen des falschen Fuse-Bits sich für immer aussperren. Habe das 
auch gleich einmal ausprobieren müssen.... War aber keine gute Idee.

Gruß Sascha

von Dennis (Gast)


Lesenswert?

Fuse-bits beim stm32? Erzähle mehr!!!!

von Marco (Gast)


Lesenswert?

Sascha schrieb:
> Hallo,
> Vorsicht ist bei den ganz neuen Derivaten geboten, da kann man sich
> durch setzen des falschen Fuse-Bits sich für immer aussperren. Habe das
> auch gleich einmal ausprobieren müssen.... War aber keine gute Idee.
>
> Gruß Sascha

Würde michauch mal interessieren. Vllt. meinst du die Option Bytes ;)

Ich habe es mal geschafft mich bei der Implementierung eines Bootloaders 
auszusperren mit Flash-Lock / Unlock ... Was außerdem noch passieren 
kann ist, dass man beim experimentieren mit Sleep-Modi oder bei einer zu 
geringen Taktfrequenz Probleme bekommt.

Schaue mal in deinen Projektsettings, ob IAR irgendwo ein Häckchen 
bezüglich der Option Bytes gesetzt hat.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.