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!