STM32G031 stop mode

[Mi N. (msx)]

Ein per SWD in den Controller programmiertes Programm soll gleich nach 
dem Start in den stop mode 0 gehen. Der Code ist auf das Wesentliche 
reduziert.

int main(void)
{
//  RCC->APBENR1 |= RCC_APBENR1_PWREN;
//  PWR->CR1 |= PWR_CR1_LPMS_0;    // bei stop mode 1
  while (1) {
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
    __WFE();
  }
}

Direkt danach beträgt die Stromaufnahme 0,46 mA und ändert sich auch 
nicht nach externem /Reset. Erst nach Trennen und neu Verbinden der 
Versorgungsspannung geht die Stromaufnahme auf 0,09 mA zurück.
Gleiches Spiel wiederholt sich mit stop mode 1. Hier geht die 
Stromaufnahme ebenfalls erst nach Neuanlegen von Vcc auf rund 6 µA 
zurück.

Liegt das am (noch) aktiven SWD Interface oder hat jemand eine Erklärung 
auf der Hand, warum POR notwendig ist?

[Vanye R. (vanye_rijan)]

Also ich habe mit deinem Controller noch nichts gemacht, spreche also 
aus Erfahrung mit anderen STM32...

> Der Code ist auf das Wesentliche reduziert.

...ich glaub eher der enthaelt vieles wesentliche nicht. Pruefe mal ob 
du nicht erstmal den Takt fuer die Stop-Hardware einschalten muss.

Und es koennte auch klug sein vorher ein Pause zu machen damit dein 
Debuginterface bei einem erfolgreichen Programm eine groessere Chance 
hat nach einem Reset noch mit dem Controller zu reden.

Vanye

[Bauform B. (bauformb)]

Mi N. schrieb:
> Liegt das am (noch) aktiven SWD Interface

Höchstwahrscheinlich. Es gibt Debug-Register(-Bits), die nur per Power 
On Reset zurückgesetzt werden. Zum Debuggen ist das natürlich durchaus 
angenehm... Das betrifft (mindestens) DHCSR, DCRSR, DCRDR, DEMCR.
RM0444, 40.6 Core Debug: "Refer to the Cortex®-M0+ TRM for further 
details" ;)

Der Unterschied zwischen JTAG und SWD wäre noch zu erforschen.

[Mi N. (msx)]

Bauform B. schrieb:
> Mi N. schrieb:
>> Liegt das am (noch) aktiven SWD Interface
>
> Höchstwahrscheinlich. Es gibt Debug-Register(-Bits), die nur per Power
> On Reset zurückgesetzt werden.

Das erscheint mir eine plausible Erklärung zu sein, denn sonst würde 
"connect during reset" nicht funktionieren.
Zusammen mit angestecktem ST-Link liegt die Stromaufnahme in den 
Stop-Modi bei rund 0,9 mA, was etwas irritiert, zumal ja auch unsaubere 
Pegel an Eingängen solche Fehlströme verursachen könnnten.
Aber gut, dann sind eben 0,9 mA umgerechnet 9 µA ;-)

[Dieter S. (ds1)]

Es gibt beim STM32G0x1 diverse Einstellungen für das Verhalten der 
Debug-Unit im Stop Modus, siehe z.B. DBG_CR, DBG_APB_FZ1 und 
DBG_APB_FZ2. Damit könnte man experimentieren und schauen ob es 
Auswirkungen auf die Stromaufnahme hat.

Bauform B. schrieb:
>
> Der Unterschied zwischen JTAG und SWD wäre noch zu erforschen.

Aber nicht beim STM32G0x1 der nur SWD hat.

[Mi N. (msx)]

Dieter S. schrieb:
> Es gibt beim STM32G0x1 diverse Einstellungen für das Verhalten der
> Debug-Unit im Stop Modus, siehe z.B. DBG_CR, DBG_APB_FZ1 und
> DBG_APB_FZ2. Damit könnte man experimentieren und schauen ob es
> Auswirkungen auf die Stromaufnahme hat.

Schon, aber für mich ist nur wichtig, ob im fertigen Zustand die 
Stromaufnahme erwartungsgemäß niedrig ist. Während der 
Programmentwicklung muß man nur wissen, daß man nichts grob falsch 
gemacht hat, was zu korrigieren wäre.
Ein paar µA Ruhestromaufnahme reichen mir aus. Und es ist schon recht 
bequem, wenn das erreicht werden kann, ohne RAM, Flash-ROM und 
Peripherie separat ausschalten und neu starten zu müssen.

[Vanye R. (vanye_rijan)]

> Schon, aber für mich ist nur wichtig, ob im fertigen Zustand die
> Stromaufnahme erwartungsgemäß niedrig ist.

Dann musst du einmal ohne Debugger neu starten. Der Debugger aktiviert 
eine Macrozelle im Controller. Daher reicht es auch nicht das Kabel 
abzuziehen.

Vanye

[Mi N. (msx)]

Vanye R. schrieb:
> Dann musst du einmal ohne Debugger neu starten. Der Debugger aktiviert
> eine Macrozelle im Controller. Daher reicht es auch nicht das Kabel
> abzuziehen.

Ach!

[Dieter S. (ds1)]

Als Ergänzung ein kurzer Test mit einem STM32G071 Nucleo-64, 
Strommessung an JP3 ("Idd measurement Jumper").

Stomaufnahme ca. 3 µA im "Stop 1 Mode".

Wenn in DBG_CR ("DBG configuration register") DBG_STOP ("Debug Stop 
mode") auf 1 gesetzt ist (das DBG Modul muss dazu in RCC_APBENR1 
eingeschalten sein) beträgt die Stromaufname ca. 650 µA.

Das DBG_STOP Bit bleibt nach einem Reset erhalten, man sieht das auch 
wenn man den Inhalt von DBG_CR ausgibt. Erst durch ein Trennen der 
Spannungsversorgung oder wenn man DBG_STOP explizit auf 0 setzt ist im 
"Stop 1 Mode" die Stomaufnahme wieder bei ca. 3 µA (auch zum Löschen von 
DBG_STOP muss man das DBG Modul zuerst einschalten).

In der Doku steht bei DBG_CR "It is asynchronously reset by the POR (and 
not the system reset)", womit sich das obige Verhalten erklärt.

[Mi N. (msx)]

Dieter S. schrieb:
> In der Doku steht bei DBG_CR "It is asynchronously reset by the POR (and
> not the system reset)", womit sich das obige Verhalten erklärt.

Danke für Deinen Hinweis. Für abschließende Messungen wird man die Kabel 
abziehen und einen POR erzwingen. Das muß man wissen und dann ist gut.

> Stomaufnahme ca. 3 µA im "Stop 1 Mode".

Bei den von mir o.g. 6 µA war noch die Stromaufnahme eines 
LDO-Spannungsreglers enthalten.