Stuck in HAL_FLASHEx_Erase

[Jim Seymour]

Posted on July 05, 2016 at 19:46

I am occasionally seeing my code go into the ditch while calling HAL_FLASHEx_Erase() to erase one page on a STM32F030 part.

I've updated to the latest STM32CubeMX (4.15.1) and the latest firmware (1.6).Has anyone seen anything like this?Other than unlocking the flash, are there any other steps that need to be done before attempting a flash erase?  Perhaps this is something like an interrupt firing when the system can't handle it?

[Tesla DeLorean]

Posted on July 05, 2016 at 22:03

Fails on or off the debugger?

Are you able to identify what ditch it ends up in? Does any of the code or vector table go through the Flash being erased?

[Jim Seymour]

Posted on July 05, 2016 at 23:25

Unfortunately, I can't easily use the debugger in my environment, so this is the old-school download-and-run method of debugging.

I have narrowed it down to the call to FLASH_PageErase() in stm32f0xx_hal_flash_ex.c (but that's hardly surprising).

[Jim Seymour]

Posted on July 06, 2016 at 00:51

We may have found our problem.

Our system receives serial data from a PC via UART1.  If we are receiving a byte while we are trying to do an erase, it seems to put the system into the ditch.  By changing the timing of when the data is sent down and the acknowledgement sent back, our problem seems to have gone away.More research is warranted, but I'm optimistic that we found the ''cause''.

[Tesla DeLorean]

Posted on July 06, 2016 at 01:40

The erase can stall the processor for a long time, basically stuffs wait-states if you touch the array while any erase or write is active. This can be more than one byte time, and could result in overruns on the USART, which you'd need to recognize and clear. If an interrupt source isn't cleared an IRQ Handler will keep reentering, and no foreground code will execute.

Watch out for watch-dogs.Probably best without a debugger, it tends to be more invasive than people anticipate. I'd generally recommend a heart-beat output (USART, GPIO or LED), and a Hard Fault Handler that outputs diagnostic state if it is triggered.

[Jim Seymour]

Posted on July 06, 2016 at 19:36

Bingo!  This was it.  Thank you!

I was getting an Overrun Error (ORE) and wasn't clearing it.  Problem has now been fixed for good.I was concerned at first because I never explicitly enable the ORE interrupt.  However, in looking at the data sheet, I see that it goes hand-in-hand with the Receive interrupt.  So for those of you rolling your own ISR (like I am), make sure you handle this alongside the RXNE!