STM32 ausgesperrt mit __WFI

[Peter (Gast)]

Hallo,
ich besitze ein STM32 Entwicklungsboard, mit dem ich zur Zeit spiele.
Nun habe ich mit dem Befehl __WFI() gespielt um den Cortex in den Sleep 
Mode zu schicken.
Programmiert und gedebugged habe ich unter Atollic Studio mit dem 
ST-Link.
Beim erreichen der __WFI() Instruktion ist mein JTAG abgeschmiert und 
seitdem habe ich auch keinen Zugriff mehr auf den Cortex.
ST-Link funktioniert, getestet mit einem anderen Entwicklungsboard.
Bei erneutem Versuch zu Flashen kommt die Fehler Meldung --> 
(TARGET_RESET_ERR) Failed to initialize target.
Habt ihr eine Idee wie das Ding wieder zim laufen kriege ?

Danke im voraus, Peter.

[Arne (Gast)]

Das Ding hat doch einen eingebauten ROM-Bootloader, der über UART1 
angesprochen werden kann. Damit schon probiert?

Ähnliches ist mir mit einem LPC1768 passiert - nur mit Flash Magic 
konnte ich ihn wieder resetten. Über JTAG ging nix mehr.

Viel Glück!
Arne

[Peter (Gast)]

Schon mal vielen Dank für die Antwort, werde ich sofort probieren.
Aber es kann doch nit sein, daß das nur so geht. Nehmen wir mal an ich 
hätte jetzt kein Entwicklunsboard, wo ich den BOOT Pin jumpern könnte, 
dann könnte ich jetzt das Ding wegwerfen oder was?

Gruß

[Arne (Gast)]

Nicht aufregen! Schlechter Start ins Wochenende ;)
Melde Dich mal bitte, ob es geklappt hat.

> dann könnte ich jetzt das Ding wegwerfen oder was?
"Eigentlich" darf sowas nicht passieren... aber die Wege des Herrn ARM 
sind unergründbar. Habs beim LPC auch nur einmal hinbekommen.

[Peter (Gast)]

So gerade gemacht und mit dem STM Tool ereased.
Geht wieder alles, BESTEN DANK Arne.
ABER das kann doch nicht sein, es muss doch noch nen Weg über JTAG 
irgendwie geben. Ansonsten ist man ja ganz schön aufgeschmissen, wenn 
zum Beispiel einer nicht den USART1 mitbestückt bei seiner Platine.

Gruß

[Peter (Gast)]

P.S: werde jetzt das gleiche Programm nochmal aufspielen um zu sehen ob 
das immer so ist.
Gruß

[Peter (Gast)]

P.S: also gleiche Situation jetzt 2mal noch mal durchgespielt.
Bis zum __WFI() gedebugged, JTAG stürzt ab (na gut HSI ist aus und den 
braucht der JTAG ja).
Aber er geht über JTAG danach wieder, war also Pech anscheinend !

Gruß

[Arne (Gast)]

Dass Dir JTAG "wegfliegt", wenn er auf WFI/WFE läuft ist IMO korrekt. Du 
schickst ihn ja in den Schlaf - vorallem die ALU. Nur die Backupdomain 
wird dann IIRC noch von Vbat gespeist. Musst halt einen INT erzeugen, 
der ihn wieder aufweckt. RTC zum Beispiel.

[Peter (Gast)]

NA toll beim dritten mal wieder weg der JTAG, also wieder über USART.
Anderes Thema:
Geht eigentlich der 24bit System Tick noch bei Sleep(nicht standby oder 
stop). Oder nur die anderen Timer ?
Gruß

[Matthias K. (matthiask)]

Welche Firmwareversion ist auf dem ST-Link und welche Atollic-Version?

[Peter (Gast)]

Matthias K. schrieb:
> Welche Firmwareversion ist auf dem ST-Link und welche Atollic-Version?

ST-Link: V1.J12.S3 JTAG+SWIM Debugger
Atollic: 2.1.0 Lite

Also bei beiden die neuste !
Gruß

[Andre (Gast)]

Ich hatte auch das Problem gehabt, dass ich nach dem WFI oder WFE 
nichtmehr mit dem uC komminizieren konnte. Das Flash-Programm brach 
immer ab.

Einfach mal das neue Programm flashen und sobald das Flash-Progamm läuft 
kurtz die "RESET"-Taste drücken.

Falls das nicht funktioniert, könntest du einmal die "Wakeup"-Taste 
ausprobieren:
[ "WAKEUP"(down) "RESET"(down) "RESET"(up) "WAKEUP"(up)]
Eins von beiden hatte bei mir jedenfalls funktioniert.

[Martin T. (mthomas) (Moderator)]

Oft hilft es in der Entwicklungsphase, beim Programmstart eine längere 
Warteschleife einzubauen (leere for in den startup-code, schleifenzähler 
volatile gegen "wegoptimieren"). Dann hat die Debugsoft-/-hardware etwas 
Zeit sich zu verbinden und kann den Core noch anhalten. Spart zumindest 
ständigen Einsatz des UART-Bootloaders zum Löschen.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Oder einen Jumper für eine Option vorsehen.
Wenn der gesteckt ist, wird der __WFx() Befehl nicht ausgeführt.

[Sven Wagner (Gast)]

Aus dem RM008 (Rev11):

30.16.1 Debug support for low-power modes

To enter low-power mode, the instruction WFI or WFE must
be executed.

The MCU implements several low-power modes which can
either deactivate the CPU clock or reduce the power of the CPU.

The core does not allow FCLK or HCLK to be turned off during
a debug session. As these are required for the debugger
connection, during a debug, they must remain active. The MCU
integrates special means to allow the user to debug software
in low-power modes.

For this, the debugger host must first set some debug
configuration registers to change the low-power mode behavior:

● In Sleep mode, DBG_SLEEP bit of DBGMCU_CR register must be
  previously set by the debugger. This will feed HCLK with the
  same clock that is provided to FCLK (system clock previously
  configured by the software).

● In Stop mode, the bit DBG_STOP must be previously set by the
  debugger. This will enable the internal RC oscillator clock
  to feed FCLK and HCLK in STOP mode.

Also zum Debuggen bei der Initialisierung die richtigen Bits setzen, 
dann geht auch JTAG noch nach WFI.

Grüße
Sven