WFI() issue using Nucleo STM32G031K8 and uVision.

[DRH]

Hi together,

I’m trying to start a new project using STM32G031. The final decision of the MCU isn’t made yet and therefore I’m currently testing the possibilities with the Nucleo STM32G031K8 board. I’m using the onboards USB debug interface. 

I start a new Keil uVision project and everything work as expected until I add WFI() at the end of my main loop. After adding it, I start a debug session and everything is fine. But after leaving this first debug session and trying to start it second one again, I got the error message “Invalid ROM table�?.

From that point it’s not possible to debug or even flash the MCU using uVision. I have to copy a hex file (strange that it’s the same source) using the storage bootloader and after that it’s possible to start a new debug session. Unfortunately with the same result, that after leaving it and trying to debug again, I got this error message.

I’m checked all ideas and tips I found here, check different “Connect and Reset Options�? because this looks to solve the “Invalid ROM table�? error for some other users, but had no success.

All programs and interfaces are updated to the current version. Currently I’m reading about DBGMCU_CR register options but I’m not using standby or stop mode so I don’t think this will change the situation. At the moment, this register is in init state.

A second strange thing is, that the same situation occurs if I use an example software provided by ST. If I use

STM32Cube_FW_G0_V1.4.0\Projects\NUCLEO-G031K8\Examples_LL\PWR\PWR_EnterStandbyMode

and delete “ LL_LPM_EnableDeepSleep();�? in line 273, I got the same result.

Maybe there is a clock or interrupt issue. Currently I’m using HSI.

Does anybody have an idea or hint where to start? Sure, I can try to switch off WFI() in debug mode, but this is only a quick & dirty fix.

I’m happy about any idea. Thank you so much. 

[MM..1]

As first one cit def

Note

WFI is intended for power saving only. When writing software assume

that WFI might behave as a NOP operation.

Maybe you have more info , but i never use WFI in code. Real setup for WFI is only call power f. This result to assembly wfi.

example

while {

...

HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

...

}

or simmilar SLEEPMode.

[DRH]

Thank you for your response. That's exactly why I use WFI(). The firmware is working interrupt triggered (by hardware or periodic timer) and I use WFI() at the end of my main loop to stop the core until the next interrupt triggers. I do this in different programs, e.g. for the STM32F3xx, and it works pretty well.

Please let me know if you see any issue with this idea. Maybe WFI() is really the wrong option to safe energy without entering Stop or Standby mode?

For the STM32F3, debugging works very good. But with the Nucleo STM32G032 including the integrated usb-debugger, I have to use NOP() instead, at least for debugging...

[DRH]

...I think it's not important, but I'm using the LL library.

[Tesla DeLorean]

Doing things that turn off parts of the chip is not helpful to external logic trying to communicate with it.

​

Alter the behaviour to permit debugging, or check DBGMCU related settings/options.​

​

To 'debug' low power and realtime critical code consider non-invasive methods where telemetry and flow information are output to a terminal.​

[DRH]

Thank's. Mmh, it's working with the STM32F3xx pretty well, but maybe you are right. The difference may also be the debug hardware. With the STM32F3 I'm using a Segger programmer, but if I remember right, the bigger Nucleo provides the same possibilities...

Are you familiar with the STM32G031 MCU. I checked different DBGMCU options (actually there are only two bits, one Standby and one Stop) but don't see any effect. Do you know that DBGMCU change WFI() behavior as well? I don't find that information in the reference manual.

[MM..1]

You can read more here interrupt - arm sleep mode entry and exit differences WFE, WFI - Stack Overflow

and here is writed too all cortex have this managed differently, then you need ...

I mean M4 can call this LL WFI an debug it. And as you can see M0+ dont. I mean when you need it as you write option to safe energy 

calling WFI() dont do any safe energy.

Use LL SLEEP or STOP mode.

[Piranha]

@MM..1​, sorry, but you are spreading misinformation.

@DRH​, your understanding of sleep mode is correct. When SLEEPDEEP bit is cleared (and that is the default state after reset), WFI instruction enters sleep mode - turns off CPU core clock until an interrupt becomes pending. If an interrupt is already pending, when WFI is called, WFI behaves as NOP. Obviously it saves the energy which would otherwise be wasted by CPU core on useless code looping/polling.

The real issue here is related to a bit for keeping debug interface active during SLEEP mode:

G0: RM0444 section 40.10.2, bit not present.

F0: RM0091 section 32.9.3, bit not present.

L0: RM0377 section 27.9.3, DBG_SLEEP bit present.

@Imen DAHMEN​, is really that bit removed in F0 and G0 series or is it a documentation issue? If it is removed, then is it somehow at all possible to debug these MCUs while using SLEEP mode?

[DRH]

@Imen DAHMEN​ , do you have any idea regarding debugging with WFI() on STM32G031?

[Imen.D]

Hello,

Thanks @Piranha​ ​ and @DRH​ for pointing out to me this discussion, and sorry for the delayed reply on this.

The DBG_SLEEP bit required is consequently unnecessary on STM32G0 product.

I can comment that on STM32G0, the FCLK and HCLK required for debug activity are kept active under sleep if debugger is active (a flag is indicating this in internal Cortex registers).

Imen

[MM..1]

if we discuss debuging only, then save energy modes is debuged by ampermeters and not debuger.

And when SLEEP is debuged simply enable systick interrupt and debuger start working. No special bits needed. Maybe you have it on STM32F3xx

STOP and STANDBY need this bits for debuging... And in this speci modes you need too STLINK or other debug with compatible firmware...

For real debuging on code then comment WFI out...is best choice

[DRH]

Hi all,

to anybody that have the same issue. It looks like I missed to switch on the DBGMCU clock....

LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_DBGMCU);

I have to make further investigation but this seems to have been the issue. Please excuse that it looks like there was a second issue behind my eyes.

[Imen.D]

Thanks @DRH​  for sharing your update and solution. This should be helpful for the Community =)

[DRH]

Hi @Imen DAHMEN​ ,

thanks. Bad news, after some further tests, it looks like there is still the same issue with WFI() with the minimalized STM example programm. Are you able to check µVision and the NUCLEO-G031K8 example PWR_EnterStandbyMode on the Nucleo of STM32G031K8? It would be very helpful.

If not, is there somebody else that have this hardware available for a quick test?