Porting stress test to STM32L4A6xx variants

[ptf18m45]

Hi Jeff-

I've been using your tick-less idle implementation and have found it to be really reliable and accurate. Well done!!!

I have a question and a couple of comments...hoping these are received with the 'good will' I intend.

In an effort to better understand/isolate an issue I've been seeing using your tick-less idle, I recently ported your test harness/project to two different custom boards. Both boards use an STM32L4A6xx variant. Both boards operate at 3.0v but one uses an STM32L4A6RG and another uses STM32L4A6VG. The later uses an external TCXO for the LSE in bypass mode while the former uses a basic crystal oscillator - both provide the required 32.768Khz clock signal. [This info is for my question below].

First, during the port effort I discovered a runtime assertion would fail (build configuration macro: USE_FULL_ASSERT, must be defined). The fix was to simply assign global variable: usTickPrio, equal to the passed priority value within your project's 'strongly' defined function: HAL_InitTick(), located in your source file: Core/Src/stm32l4xx_hal_timebase_tim.c. Without the required assignment, the assertion will occur later when HAL_InitTick() is called again rooted in the call stack starting with SystemClock_Config(). This is because global: 'usTickPrio', is intentionally assigned (by ST's HAL) an "invalid" priority (i.e. numerical value 16) and is expected to be correctly assigned a valid priority when HAL_InitTick() is called. See ST's HAL implementation of this same function name. The first time HAL_InitTick() is called (from HAL_Init()), the passed parameter comes from macro: TICK_INT_PRIORITY.

Also, when printing out the test results (while test mode 2 & 3 are active), it would be really helpful to see some sort of header (and footer) banner printed at the start (and end) of a new test mode. Optionally, maybe printing some sort of index used to determine which of the 60 second periods is currently running. Therefore, an observer would see each 60 second test result listed with a unique test period counter...or a running total of minutes since the start of the test. This would be really helpful in test mode 3 where you stress the tick-less idle functionality. If failure is detected, one can quickly determine how far into the test it occurred. This paragraph is just a suggestion...not trying to be critical.

Q) The errata issue you referenced for the STM32L476xx variants (and worked around using build macro: configMIN_RUN_BETWEEN_DEEP_SLEEPS), indicates a "brown-out condition" will occur if STOP mode is entered too soon after last leaving STOP mode. I'm assuming if this condition is present, the MCU will reset?. Is this assumption accurate? Should I expect a reset will occur IMMEDIATLY when attempting to come out of STOP mode? If not, I'm curious what kind of behavior you saw that indicated a brownout condition occurred.

I ask because I'm trying to track an issue where it would appear the MCU can sometimes fail to come out of STOP mode correctly (or completely) - this happens very infrequently. At this point, we aren't sure if this is related to tick less idle (something we feel unlikely) or some unknown/undocumented errata issue for the L4A6 variants (something we feel is more likely). We have only seen this issue on the STM32L4A6VG, using the LSE in bypass mode. I ran your test harness on the xxxA6RG over the entire weekend without failure.

Using our custom board and software, we have seen a couple conditions where our 4 second watchdog timer would actually reset while in STOP mode. What is puzzling to us is we updated the flash option bytes to disable the clock driving the IWDG when in STOP mode. Knowing the maximum tick-less idle period is about ~2 seconds because LPTIM1 is a 16 bit counter, we are investigating whether or not the MCU is "partially" waking up from STOP, but failing to come completely out of STOP in order to execute the next instruction after WFI. This is based upon knowing the IWDG clock gets turned back on (because a valid LP wake-up ISR became pended) and yet, about 4-6 seconds later a reset occurs due to a WD expiration. This WD reset occurs ~4 seconds AFTER the MCU entered STOP mode PLUS the additional period of time before the valid LP wake-up ISR becomes pended (i.e. the LPTIM1 expires or some external wake-up pin transitions).

With all of this detail, I "think" I was able to reproduce this issue using your test harness application (running test mode 3) on our board. But I was only able to do this only once (or possibly two times), but only on the xxxA6VG.

Again, I'd be curious to know what you experienced with the documented errata for the STM32L476xx. We're simply trying to understand if this is our issue or if it is something else.

Thanks again for an awesome tick-less idle implementation! Looking forward to your response.
Phil F.

[jefftenney]

Hi Phil,

Glad lptimTick.c is working for you.

Regarding the assertion failure, CubeMX generates stm32l4xx_hal_timebase_tim.c, so I'll correct their mistake from a user-code section in main.c. That way the project remains modifiable in CubeMX and compatible with further code generation. Thanks for reporting that.

I never observed any failures related to the errata regarding minimum run time between deep sleeps. I just saw the errata sheet and wrote a workaround. Have you tried a workaround -- either the one in ulp.c or your own?

With regard to your watchdog timeout, I agree it's very weird. You could add code to save the RTC captures made in the tick-hook function (test modes 2 and 3). You could save the captures to RTC RAM for example. Then add code to capture the RTC value after a watchdog reset. When the watchdog reset happens, compare the time stamps. Sounds like there will be several seconds' difference, indicating that the MCU lost its mind well before finally being reset by the watchdog. However, if the tick-hook timestamp is within TICK_TEST_SAMPLING_INTERVAL_MS milliseconds (probably 10), then the watchdog may have lost its mind instead. (I haven't studied the IWDG so can't comment on what might cause it to trigger a reset.)

It is interesting that the watchdog reset occurs only with the TCXO hardware. If it were me I'd be turning on the LSE oscillator anyway (so, disable bypass) even though you have a clock signal coming out of your TCXO. Should work just fine, and it should give you another data point.

Your suggestion to decorate the test results on the terminal a little bit is good. Would you want to submit a PR?

[ptf18m45]

Hi Jeff-

Thanks for the quick response. We implemented something similar to what your test project does (using SysTick peripheral) to block re-entry into STOP for a few micro seconds. I didn't seem to help our issue - so that is why I was curious what you had experienced.

With regards to the HAL changes, I'm not familiar with the "tricks" of using ST's HAL. Our codebase was originally written against ST's Standard Peripheral Library for an F1 and later using an F4 MCU. So we've never used the CubeMX tool or any of the auto-generated code.

I ran your stress test overnight and it is still running on both boards - all looks really good. Basically, we're looking for a lock-up or reset. Nothing yet (at this point we don't expect it...just trying to check off some boxes).

We did make some progress in our investigation trying to understand the "getting stuck in STOP mode".

[The remainder of this comment is really just informational. I don't have any further questions or concerns about Tick-less Idle. This is more background for others who may be integrating your Tick-less Idle code.]

Our issue is really difficult to catch and mostly impossible to debug. We added code to drive a GPIO pin high just before calling WFI and then drive the pin low just after calling WFI (in your LPTIM1 driver code). Using a scope we always see the pin driven high during periods of STOP and will pretty much always see the pin driven low upon exit from STOP. But very infrequently, when we expect the STOP mode to exit due to LPTIM1 timer expiration, the MCU never executes the instructions following WFI.

Because we have the Watch Dog (WD) clock gated while in STOP mode (using option bytes), we are confident we are correctly entering STOP since we can confirm a WD reset never occurs if we simply disable LPTIM1 prior to executing WFI. With that said, when we do experience this errant behavior, we get the WD reset approximately 4 seconds (our WD time-out period) AFTER we think the LPTIM1 should have expired. This means the MCU appears to have started to exit STOP (by restarting the clock to the WD), but it fails to make any more progress until the WD actually expires. Interesting, all output GPIO pins remain "held" until the WD reset. Unfortunately, for us, if we manually wait for this condition to occur (painful as it sounds), we have about a 2 second window when you would think we could use our J-Link to HALT the MCU and interrogate some of the MCU registers. But when this errant condition does occur, the SWD interface is lost and only a reset will bring it back. Thus, we're pretty much blind in what the state is when the MCU is stuck in STOP.

Our progress in resolving our issue appears to be rooted in how the MCU is clocked prior to entry into STOP mode. Due to our requirements, we must use a highly accurate TCXO for the System Clock source - but only when we need to run "fast". Most of the time we can run "slow" driven by the HSI.

Inspired by your demo project, we made some quick changes to assume upon exit from STOP mode the HSE could still be selected as the clock source by the MCU (because an ISR was pending when WFI was executed so WFI was treated as a NO-OP), but that something wasn't fully turned back on during the no-op operation. Long story short, we found that if we simply turn off the HSE and always ensure we run from HSI, a quick return to STOP will occur the second time with HSI selected as the System Clock source. This quick change seems to make our system more stable.

Ideally, we would simply like to always enter STOP mode executing from HSI. This may be what we end up doing. Again, that approach is inspired by your demo code. But for now, bottom line, we seem to be more stable when we switch to HSI out of exit. The reason we do this is historical and it was quick to change it. Changing the code to ensure HSI is selected in the "pre" hook (the function called just before WFI instruction) seems like a "more correct" solution...it just requires some significant architecture changes that we want to avoid in the near term.

Anyways...just a quick (but deep) update. I think your Tick-less Idle implementation is excellent! I only wish ST would have allocated a 32 bit counter to LPTIM1 so we could remain in STOP for much longer periods (rather than the maximum of 2 seconds).

Thanks again Jeff!
Phil F.