Unknown crash

[nilesh-dryad]

Hello Jeff,

You did wonderful job with tickless idle. It is working perfectly fine and saves a lot of power. I am running system with 160Mhz when it is not in idle mode and it also goes to 25Mhz during tickless mode.

I have following MACRO defined.

#define SUPPORT_VREG_RANGES_1_THROUGH_3
#define SUPPORT_MSI_AT_48MHZ

Sometime I am getting crash at two location randomly. I tried to find the cause but I couldn't find anything. I am attaching the image for the location where I am getting the crash.

And line number 556 in below image.

It would be great help, if you have any idea.

[jefftenney]

Are these crashes occurring only while debugging? If so, this is a known silicon bug on STM32L4+, and it is a silicon bug on the STM32U5 too. See https://community.st.com/s/question/0D53W00001YaehVSAR/waking-from-stop-mode-causes-hard-fault-but-only-when-debugging. See 2.2.16 in the STM32L4+ errata. The erratum is called "Wrong instruction fetches from flash memory upon wakeup from Sleep or Stop mode when debug in low-power mode is enabled". As of this writing the STM32U5 errata sheet doesn't yet include this bug, but the bug is definitely in the silicon. See this commit for the workaround I chose for the LPTIM-Tick-U5 demo program.

The silicon bug occurs only while debugging. More precisely, the bug occurs only while DBGMCU_CR_DBG_STOP is set. Be aware that this bit might remain set even after debugging ends depending on the debugger and on the way the debug session ended. A power cycle is sure to clear DBGMCU_CR_DBG_STOP.

[nilesh-dryad]

@jefftenney Thank you for your reply. EXTI line 5 is added recently (just few days back) but it is just empty function because it is new feature that we are going to use in future. We can ignore that as of now but I can try disabling the STOP mode. I will keep you posted.

[nilesh-dryad]

@jefftenney I have an update. After removing STOP modes, none of my devices (total 6 devices) got assert at line 553. They are all running since more than 48 hours.

[jefftenney]

Does your firmware activate the ICACHE or DCACHE? I'm thinking about erratum "2.2.11 ICACHE and DCACHE access might be corrupted after exiting Stop 2 and Stop 3 modes".

[nilesh-dryad]

Yes my firmware activates both but I am always using STOP1 mode. I have commented STOP2 part.

   int useDeepSleep = pdFALSE;
//   if (xDeepSleepForbiddenFlags == 0)
//   {
//      useDeepSleep = pdTRUE;
//      #define PWR_CR1_LPMS_STOP2 PWR_CR1_LPMS_1
//      MODIFY_REG(PWR->CR1, PWR_CR1_LPMS_Msk, PWR_CR1_LPMS_STOP2);
//   } else
//   if ((xDeepSleepForbiddenFlags & ~ulpPERIPHERALS_OK_IN_STOP1) == 0)
//   {
      useDeepSleep = pdTRUE;
	  #define PWR_CR1_LPMS_STOP1 PWR_CR1_LPMS_0
	  MODIFY_REG(PWR->CR1, PWR_CR1_LPMS_Msk, PWR_CR1_LPMS_STOP1);
//   }

   if (useDeepSleep)
   {
      rccCrSave = RCC->CR;
      rccCfgrSave = RCC->CFGR1;
      #ifdef SUPPORT_MSI_AT_48MHZ
      {
         rccIcscr1Save = RCC->ICSCR1;
      }
      #endif
      #ifdef SUPPORT_VREG_RANGES_1_THROUGH_3
      {
         pwrVosrSave = PWR->VOSR;
      }
      #endif

      SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
   }

[jefftenney]

In that case, the problem seems to be unrelated to ICACHE and DCACHE. However, it might still be worth an experiment to turn them off and retest. I think the root cause of the issue is probably unexpected hardware behavior.

Is it possible for you to build and test without SUPPORT_VREG_RANGES_1_THROUGH_3? You would need to move the clock down to < 25 MHz, either permanently or at least any time vUlpPreSleepProcessing() might attempt STOP mode. Here's what I'm thinking. Your previous experiments tie the issue to the use of STOP mode. My only theory to explain the issue is that something is delaying the tick ISR too much. So maybe the wake-up-from-STOP-mode code is taking too long? The wake-up code that supports VREG ranges 1 through 3 does look a little suspicious because it loops waiting (indefinitely) for the hardware to respond.

         do
         {
            PWR->VOSR = pwrVosrSave;
         } while (PWR->VOSR != pwrVosrSave);

For my part, I could make a branch of LPTIM-Tick-U5 that runs at 160 MHz and see if maybe the existing tests catch something.

[nilesh-dryad]

@jefftenney STM32U575 Errata sheet is also updated with this hardfault.
https://www.st.com/resource/en/errata_sheet/es0499-stm32u575xx-and-stm32u585xx-device-errata-stmicroelectronics.pdf

[jefftenney]

Thanks. Erratum 2.2.18 in that document doesn't quite match 2.2.16 in the L4+ errata. Wonder if its a separate issue.