STM32F091 how to detect suspected CPU stall through Flash access?

[Oliver Sedlacek]

I'm having trouble with my IAP erase and write of Flash in my custom bootloader. I need to overlap comms activity with Flash erase so comms doesn't time out, but despite attempts to force the bootloader code, ISRs and vector table into SRAM, my suspicion is that I'm still getting a CPU/bus stall, as described in RM0091 section 3.2.2. What I see is ISRs not being entered to service the UART, giving me read overruns. So my questions is, "How can I tell if the CPU/bus is stalling, and what code is initiating the Flash access?"

Is there any chance the prefetch controller is the culprit?

[waclawek.jan]

Hi Oliver,

A quick test is to toggle a GPIO pin in the main loop and perhaps one more in the UART interrupt, and observe on oscilloscope/LA.

If there's some code accessing the FLASH during programming, I don't think there is a simple way to tell, which one is it. So it may be easier to strip down the code to bare minimum and start from there (or maybe the other way round, cutting down pieces from the code until it stops stalling).

If everything fails, post the code (hopefully minimal by that point). Do you have a 'F091 Nucleo? That would be a nice common platform for testing.

Jan

[Oliver Sedlacek]

Jan, I'm working towards a 'toggle until it stops' test harness. My main loop needs to service both pseudo tasks, comms and Flash, which is complicating things.

In the mean time I've commented out the actual write and actual polling and my problem goes away, so I'm homing in on it. I'm now going to try replacing the polling loop with a fixed worst case wait as that should split the problem between write and poll.

Update, using a fixed timer instead of polling the FLASH->SR for EOP makes no difference

[Tesla DeLorean]

I doubt it is prefetching much on a CM0, something more mundane that is touching the flash array, or the controller.

Need to be very sure the code in RAM isn't touching any code in FLASH, ie library or helper routines to do division, multiplication or modulus, etc that the compiler might have in-lined a function call.

When I'm doing flashing from RAM, the code is all very self-contained and transparent

[Oliver Sedlacek]

I've turned the prefetch controller off, no change. I've inspected the map file and stepped through the code at assembler level without seeing anything suspicious.

[Oliver Sedlacek]

Cracked it! I thought I was turning off the SysTick interrupt using the NVIC but it turns out you can't do that! Masking the SysTick interrupt in the control register is what you have to do. The fact that the HAL_NVIC_DisableIrq() call doesn't trouble to tell you that you've specified a non-maskable source as a parameter doesn't help.

[waclawek.jan]

Hi Oliver,

nice catch!

https://community.st.com/s/question/0D50X00009hphn8SAA/hard-fault-after-configure-systick

Jan