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.

[Tesla DeLorean]

>>At this point I suspect to be an issue in the silicon and should probably be added to the errata.

As convenient as that might be, it is much more likely to be something else

The debugger/probing is likely to be extremely invasive in the system. The true test would be a well instrumented and stand-alone app, that could output Hard Fault and register level monitoring/dumping.

The HAL is also a rats nest of potential issues, especially when it comes to interrupt context, call-backs, etc. and a lot of unstated limitations and hazards.

ST has a cursory presence here, and certainly not with the HW team who moved to other things when the chip taped out. You might want to work with your FAE to root cause the issue.

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

[BPaik]

I considered debugger interference. While I wouldn't say this is "well instrumented", I did create a conditional in main that sets an LED on the board if the FLASH.SR register is non-zero. Running the stand-alone app showed that FLASH.SR register is still being set.

[Tesla DeLorean]

Fair enough. Now you have to find some people with G4 hardware who are willing to invest some time it.

Work with your FAE if you have that type of relationship with ST, or try filling an Online Support Request.

[BPaik]

I mentioned this in previous posts, but the instruction that causes the FLASH.SR register to be set is "__HAL_TIM_CLEAR_IT(&htim1, TIM_IT_CC3)". I found that calling this before the timer initialization sets the FLASH register, but calling it after "MX_TIM1_Init()" does not.

"Now you have to find some people with G4 hardware who are willing to invest some time it." - that's essentially what I was attempting to do by posting here. I already have a workaround by simply clearing the FLASH status register before calling the EEPROM initialization routine, so I don't have much incentive to invest more time into this, though it would be nice to get confirmation from ST. I don't have an FAE, and I'm working solo on this project, but I figured ST would probably want their customers to be aware of this as I'm likely not the only person it has affected.

[BPaik]

The post I was responding to wasn't giving advice on how to "analyse this in a more hands-off way", it was instructing me to step through code - which I had already done as explained in my original and subsequent posts. If instead a suggestion was given on how to test the code in a more nuanced way, I would not have responded with "this is already explained in detail".