Flash erase blocking GPIO updates

[link87]

I am testing doing flash erase while running code from internal SRAM on a STM32F072B Discovery Board. Having initializing everything with code running in flash, I call a function where itself and all its dependencies exist in RAM. I've verified this in many ways: code analysis, stepping through debugger, etc. I have also copied the ISR vectors to RAM at 0x2000_0000 and used SYSCFG_CFGR1 register to remap SRAM to 0x0000_0000.

I have TIM2_CH1 setup as a 100kHz timer and increment a tick variable each interrupt. The interrupt also toggles a GPIO pin every pulse. Currently that is connected to an LED so I can visualize what's going on, but I have tested with a bare pin at GPIO_SPEED_FREQ_HIGH as well with the same results.

All of this works fine as long as I don't do the flash erase cycle. But as soon as I erase a few pages of flash, the LED starts flickering quite a bit like the GPIO bus is being blocked. The datasheet says that flash should only block the flash bus; running in SRAM is supposed to avoid CPU stalls. The GPIO also doesn't seem to be on the same bus. So my question is why is this happening? I have attached some logic analyzer captures of the GPIO. In the macro view you can see two white blocks on the left and right ends. This is the 100kHz signal. Once the signal becomes sparse that is when flash erase is in progress. The toggling is extremely slow and erratic during this time frame. I also attached a close up on the 200kHz signal to show that it is functioning fine outside of the flash erase cycle.

I've also attached the project which is based off one of the examples in the SDK. I copied many functions into My_XXX variants to place them into RAM.

[link87]

Unfortunately the rep never wanted to look here and the case is now closed. He wanted me to recreate the project using the latest CubeMX and do other things that were very different to my original problem so the code evolved a lot over time.

I wanted to try to figure it out so I did find the old code I originally was working with for this forum post and tried to reproduce it. Unfortunately too much time has passed and I can't figure out what is different but I can't reproduce the same behavior. Notably fixing the same problem that made my current code work did not solve the original problem. My guess is there is somewhere else that I was inadvertently accessing some flash-based data.

Loading the entire project into SRAM does fix the problem so I don't think it's actually an issue with the chip at all. I was specifically trying to avoid loading all code into SRAM so that isn't really a solution I was interested in. But I was able to fix it in my latest code to have the mix of SRAM and Flash. Sorry I couldn't give a more satisfactory answer.

[waclawek.jan]

I see. Thanks for the effort.

JW