FLASH SR error set after clearing TIM interrupts before timer initialization

[BPaik]

When using a TIM timebase (rather than systick), the PGSERR bit in the FLASH.SR register gets set after calling HAL_InitTick. Using the debugger, I found that the specific line that causes the flash error is "__HAL_TIM_CLEAR_IT(htim, TIM_IT_CC2)". This appears to be the case when using different timers as the timebase as well.

I am using STM32CubeIDE 1.7.0, STM32Cube FW_G4 V1.4.0, and GNU Tools for STM32 (9-2020-q2-update). My target is the Nucelo G431RB.

[TDK]

The only way I can think of in which this makes sense is if the relevant timer interrupt uses the flash in some way, perhaps trying to initialize the EEPROM page. Set a breakpoint in the relevant interrupt handler and trace execution.

[BPaik]

The FLASH.SR register gets set with the PGSERR bit before any EEPROM initialization has occurred. I even removed the EEPROM code and it still shows the same behavior. I tried what you said and put a breakpoint in the ISR. Right after calling "HAL_NVIC_EnableIRQ(TIM1_TRG_COM_TIM17_IRQn)", the interrupt triggers and jumps to "HAL_TIM_IRQHandler". Stepping through the ISR I can see that the FLASH.SR register is set after calling "__HAL_TIM_CLEAR_IT(htim, TIM_IT_CC2)" in the "capture compare 2 event" section. Also, everything I've described so far is stock code generated by CubeMX.

[TDK]

HAL_TIM_IRQHandler isn't the entry point of the IRQ handler. Should be able to see the entry in the call stack.

> Stepping through the ISR I can see that the FLASH.SR register is set after calling "__HAL_TIM_CLEAR_IT(htim, TIM_IT_CC2)" in the "capture compare 2 event" section

So the flag is clear before this line and then it is set after clearing the CC2 flag? Seems like a hard sell to me. I don't see anything about it in the errata sheet.

I'm not familiar with how HAL sets up a TIM timebase, but it seems odd that the CC2 event is used instead of the update event.

[BPaik]

"TIM1_TRG_COM_TIM17_IRQHandler" should be the entry point where "HAL_TIM_IRQHandler(&htim17)" is called. Strangely enough when I resumed testing, the FLASH fault changed so that it now trips in the capture compare 3 section despite not changing any code. Your understanding of my description is correct. I've included an image that shows screenshots immediately before and after "__HAL_TIM_CLEAR_IT(htim, TIM_IT_CC3)" in debug.

[TDK]

Well that's weird. I am as stumped as you are. If the spot where it happens moves around as you change code, it could be a latent result from an operation that is started earlier somewhere.

[BPaik]

The section where the FLASH error occurs changed even though I didn't change any code. The error occurs so early on that there don't seem to be any other operations to interfere. The stack trace in chronological order looks like this: main() -> HAL_Init() -> HAL_InitTick() -> HAL_NVIC_EnableIRQ() -> interrupt -> TIM1_TRG_COM_TIM17_IRQHandler() -> HAL_TIM_IRQHandler()-> __HAL_TIM_CLEAR_IT(). "HAL_Init" is the first function call in "main", and everything leading up to the interrupt are CubeMX generated HAL functions, so I don't see how any of my code could be causing this. If I have time later I'll create a new project and try to reproduce the issue exclusively with CubeMX generated code. I am running this on a nucleo board so if I can come up with simple instructions to reproduce the issue maybe someone at ST will take notice.

[BPaik]

I played around with this a bit more and found the minimal setup to reproduce the issue.

1. Create a new STM32Project in STM32CubeIDE and select the Nucleo-G431RB board configuration.
2. In CubeMX, change the timebase source from SysTick to TIM17.
3. Go to the Timers section in CubeMX, select TIM1, and set the clock source to "Internal Clock".

"HAL_Init" will now cause the FLASH.SR register to change from 0 to 128. If "Internal Clock" is never selected in the TIM1 configuration, FLASH.SR will not change value after "HAL_Init". At this point I suspect to be an issue in the silicon and should probably be added to the errata.

[waclawek.jan]

> "HAL_Init" will now cause the FLASH.SR register to change from 0 to 128.

Step through HAL_Init() and functions it calls, and find out, where does this happen.

JW

[BPaik]

This is already explained in detail in the previous posts.