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.

[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.

[Tesla DeLorean]

>>This is already explained in detail in the previous posts.

Pool here is pretty shallow.

Stepping-thru the code is perhaps akin to seeing how the meat grinder works with your fingers in it, suspect you want to analyse this in a more hands-off way so you can remove the invasiveness of the debugger/tools from the problem space.