Wrong PC (progam counter) when exiting ISR

[Brigei]

Hi,

i'm using a STM32L031. In my code i first initialize the MCU (FLASH, CLOCK, INTERRUPTs, GPIOs), start the LPTIM (running on LSI), then slow down the MSI clock, start the timer22 for PWM and go into low-power sleep mode.  When i let the program run i experience an hard-fault after exiting the ISR (count = ccr) from the LPTIM because at the moment when r7 and PC gets popped from the stack PC gets a wrong value and suddenly points to RAM instead of FLASH. The strange thing for me is also, that when i don't use the LPTIM for waking up the MCU, but use a GPIO (EXTI) ist works fine. It also works fine when i don't go into low-power sleep mode but into stop-mode and then let the LPTIM wake up the MCU. In this case of course the PWM doesn't work while in stop-mode.

So can someone help me out an tell me why the pc gets a wrong value?

Here my example code:

#######################################################

int main(void){

// Initialize

FLASH->ACR |= FLASH_ACR_PRFTEN; // Enable Pre-Fetch

RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN; // Clock für Systemconfig aktivieren

RCC->APB1ENR |= RCC_APB1ENR_PWREN;

// Clock setup

RCC->ICSCR &= ~(0b111 << 13);

RCC->ICSCR |= 0b101 << 13;

while(!(RCC->CR & RCC_CR_MSIRDY));

// GPIO setup

RCC->IOPENR |= RCC_IOPENR_GPIOAEN; // Aktivieren des Clock-Gates für GPIOA

GPIOA->MODER &= ~(0b11); // Pin PA0 als Input - BUTTON

GPIOA->PUPDR |= 0b10; // Pin PA0 Pull-down

EXTI->IMR |= 0b1; // Interrupt Maske für PA0

EXTI->RTSR |= EXTI_RTSR_RT0; // Konfigure Interrupt für Rising Edge für PA0

NVIC_SetPriority(EXTI0_1_IRQn, 1); // Priorität von PA0 Interrupt auf 0

NVIC_EnableIRQ(EXTI0_1_IRQn); // Interrupt von PA0 aktivieren

PWR->CSR |= PWR_CSR_EWUP1; // Enable PA0 als Wakeup Pin

GPIOA->MODER &= ~(0b11 << 30); // Pin PA15 als Input - DPS INTERRUPT

EXTI->IMR |= 0b1 << 15; // Interrupt Maske für PA15

EXTI->FTSR |= EXTI_RTSR_RT15; // Konfigure Interrupt für Falling Edge für PA15

NVIC_SetPriority(EXTI4_15_IRQn, 2); // Priorität von PA15 Interrupt auf 0

NVIC_EnableIRQ(EXTI4_15_IRQn); // Interrupt von PA15 aktivieren

GPIOA->MODER &= ~(0b11 << 14); // Pin PA7 auf Alternate Function Mode

GPIOA->MODER |= 0b10 << 14;

GPIOA->AFR[0] |= 0b0101 << 28; // Pin PA7 mit TIM22 CH2 verbinden

GPIOA->MODER &= ~(0b1111 << 6); // PA4 (EN1) - PA3 (EN2) - Konfiguration Verstärker

GPIOA->MODER |= (0b0101 << 6); // PA4 + PA3 auf Output Mode

GPIOA->MODER &= ~(1 << (9 * 2)); // PA9 auf Alternate function mode

GPIOA->MODER &= ~(1 << (10 * 2)); // PA10 auf Alternate function mode

GPIOA->OTYPER |= 1 << 9; // PA9 auf open-drain

GPIOA->OTYPER |= 1 << 10; // PA10 auf open-drain

GPIOA->OSPEEDR |= 0b11 << (9 * 2); // PA9 auf High-Speed

GPIOA->OSPEEDR |= 0b11 << (10 * 2); // PA10 auf High-Speed

GPIOA->PUPDR |= 1 << (9 * 2); // PA9 auf Pull-Up

GPIOA->PUPDR |= 1 << (10 * 2); // PA10 auf Pull-Up

GPIOA->AFR[1] |= 1 << 4; // PA9 mit I2C1_SCL verbinden

GPIOA->AFR[1] |= 1 << 8; // PA10 mit I2C1_SDA verbinden

GPIOA->MODER &= ~(1 << ((6 * 2) + 1)); // Default 11 -> 01 -> PA6 auf Output Mode

GPIOA->ODR |= (1 << 6); // PA6 auf HIGH

__enable_irq();

// LPTIM setup

piepsen = 1;

RCC->CSR |= RCC_CSR_LSION; // LSI aktivieren

while(!(RCC->CSR & RCC_CSR_LSIRDY)); // Warten bis LSI Ready

RCC->CCIPR |= RCC_CCIPR_LPTIM1SEL_0; // LSI als Clock Souce für LPTIM

RCC->APB1ENR |= RCC_APB1ENR_LPTIM1EN; // Aktivieren des Clock-Gates für LPTIM1

NVIC_EnableIRQ(LPTIM1_IRQn);

NVIC_SetPriority(EXTI0_1_IRQn, 3); // Priorität von PA0 Interrupt auf 0

LPTIM1->CFGR |= 0b101 << 9; // Prescaler auf 32 -> 37kHz -> 1156.25 Hz

LPTIM1->IER |= 0b11;

LPTIM1->CR |= LPTIM_CR_ENABLE; // LPTIM starten

LPTIM1->ARR = (1156.25 / 1000)*(200); // Auto Reload Register

LPTIM1->CMP = (1156.25 / 1000)*100; // Capture Compare

LPTIM1->CR |= LPTIM_CR_SNGSTRT; // Timer start in Single Shot mode

// Slow down clock

RCC->ICSCR &= ~(0b111 << 13);

RCC->ICSCR |= 0b001 << 13;

while(!(RCC->CR & RCC_CR_MSIRDY)); // Wait for MSI is ready

// Start TIMER 22

RCC->APB2ENR |= RCC_APB2ENR_TIM22EN;

TIM22->ARR = 131072/500; // Auto-reload value (period)

TIM22->CCR2 = 131072/500/2;

TIM22->CCMR1 |= 0b110 << 12; // PWM mode 1

TIM22->CCER |= TIM_CCER_CC2E; // Enable channel 2 output

TIM22->CR1 |= TIM_CR1_CEN; // Enable TIM22

// Enter LOW-POWER SLEEP MODE

while (FLASH->SR & FLASH_SR_BSY) {} // Auf Flash warten bis alles erledigt

FLASH->ACR |= FLASH_ACR_SLEEP_PD; // FLASH schlafen legen

PWR->CR |= PWR_CR_LPSDSR; // Volt Regulator in Low Power Mode --> einziger vorteil wäre sonst schnellerer wake-up

__WFI();

while(1);

}

The ISR looks like this:

void LPTIM1_IRQHandler(void) { // Überwachung Piepsdauer

if(LPTIM1->ISR & 0b1){ // Capture Compare Interrupt -> Piepsen AUS

status = 3;

LPTIM1->ICR |= 0b1;

TIM22_Stop(); // Abfrage damit nicht Gamification unterbrochen wird

}

else{ // Auto Reload Register Interrupt -> Pieps-Pause AUS

piepsen = 0;

LPTIM1->ICR |= 0b1 << 1;

LPTIM_Stop();

}

}

#####################################################################

Screenshots:

1. In screenshot "Beginning" you can see the system right after the ISR was triggered.

2. Screenshot "Before" was taken just before the hard-fault happens.

3. Screenshot "Hard-Fault" doesn't need an explanation 

Thanks in advance

Greetings from Salzburg, Austria

[waclawek.jan]

Interesting.

In the problematic case, the ISR stacking goes wrong and only one of the 8 words (PSR) gets actually stacked. As if the SRAM would be unavailable for the core immediately after the wakeup.

Now I don't know why is that, but to me this thing is suspicious in your code:

// Slow down clock
RCC->ICSCR &= ~(0b111 << 13);
RCC->ICSCR |= 0b001 << 13;
while(!(RCC->CR & RCC_CR_MSIRDY)); // Wait for MSI is ready

Here, you switch the MSI speed *twice* - first you set it to range 0 and immediately after that to 1. Don't do that.

Try to place a bunch of NOPs or a loop just before WFI, just as an experiment.

Also, how are RCC_AHBSMENR bits set?

JW

PS.

> has the value 0x80001B63 which ist not aligned?! Should it be? After the value is popped the program jumps correctly to 0x80001B62

That's OK. The Cortex-Mx processors don't use the original 32-bit ARM instruction set, but the 16-bit Thumb instruction set, and there, the LSB of address indicates the Thumb mode.

[Brigei]

Thanks for your reply. I just tried:

1. Avoiding setting clock to "0", instead directly setting it to desired speed --> still same behavior HARD-FAULT

2. 30 NOP in front of _wfi (actually visible in assambler code) --> still same behavior HARD-FAULT

3. All bits in RCC_AHBSMENR are 1 --> everything activated in sleep-mode

[Sarra.S]

Hello @Brigei 

check STM32L031xx/L041xx device errata - Errata sheet section 2.1.2 : 

[waclawek.jan]

Hi @Sarra.S ,

IMO the quoted erratum does not apply to this case:

The erratum talks about invalid FLASH fetch. This is obviously not the case here: the first FLASH fetch after wakeup is the interrupt vector fetch, and that is obviously correct, as execution reaches the ISR. The problem is the incorrectly stacked registers. In other words, the problem is *not* FLASH fetch, the problem is *register stacking in SRAM fails*, i.e. it's the SRAM which is problematic after wakeup.

JW

[Sarra.S]

Hey @waclawek.jan, 

This is related to the flash wakeup time when the system is waking up from LPSLEEP. 

The first instruction fetch from Flash after waking up is incorrect due to the Flash not being ready (as described in the errata, recovery time is needed), the POP that attempts to restore the PC from the stack could end up fetching the wrong address for the PC, and the CPU will resume execution at an incorrect address leading to hardFault. 

As the workaround suggest and I think @Brigei tested it, removing the line that puts the flash in power down mode will solve the issue. 

[waclawek.jan]

Hi @Sarra.S ,

The first instruction fetch from Flash after waking up is incorrect due to the Flash not being ready (as described in the errata, recovery time is needed), the POP that attempts to restore the PC from the stack could end up fetching the wrong address for the PC, and the CPU will resume execution at an incorrect address leading to hardFault.

This is not the case here.

If you look at screenshot in 3.jpg in @Brigei 's post above, PC points to the correct address of first instruction in LPTIM1_IRQHandler(). However, what is not correct there are the stacked registers.

Also, the whole thread is about the fact, that the hardfault does *not* occur immediately after the wakeup, but that *whole* LPTIM1_IRQHandler() after wakeup is executed correctly (that's many many fetches from FLASH, all correct), and that the hardfault occurs upon *exit* from LPTIM1_IRQHandler(), when the incorrectly stacked PC is popped from the stack.

So, as I've said above, the problem is *not* incorrectly woken up FLASH, but that 7 out of the 8 register values stored to RAM during the stacking upon ISR entry are not written by the processor into RAM at all, and those RAM places retained their previous values. Again, refer to the screenshots in @Brigei 's post above and their descriptions, they very clearly indicate the problem, and it very obviously is NOT consequence of incorrect FLASH fetch.

That the problem appears to go away by disabling FLASH powerdown, is IMO coincidental, thus without further investigation of the true mechanism of problem should not be considered to be a solution to this problem.

JW

[Sarra.S]

Hello @waclawek.jan 

I'm still investigating, meanwhile, ideally @Brigei shares a project to debug or more screenshots of all the registers/disassembly 

[waclawek.jan]

@Brigei,

Do you use some sort of (maybe homebrew) RTOS?

Post a minimal complete compilable example exhibiting the problem.

JW

[Brigei]

Hi,

you'll find the project attached.

About RTOS: I do have installed homebrew but only for terminal packages. I'm working on my macbook with STM32CubeIDE Version: 1.14.1 Build: 20064_20240111_1413 (UTC).

[Sarra.S]

Hello @Brigei and @waclawek.jan 

When disabling debug in low power mode before entering the debug session, the hardfault is no longer visible, this is probably due the desynchronization between core and its subsystem peripherals (flash).

This issue is under investigation in internal ticket 81363.