2025-05-24 1:26 PM
I understand you can't erase the same bank you are running code in. Or something like that. But I am confused on the STMG0 because this one only has a single bank. So how do I use Flash to emulate EEPROM if I am using flash to run my code. Everything has been working. not sure what I changed but now when I do an erase I am getting an exception. Maybe I should not do the background interrupt based erase!?
Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)
HardFault_Handler() at stm32g0xx_it.c:100 0x8013964
<signal handler called>() at 0xfffffff1
HAL_TIM_IRQHandler() at stm32g0xx_hal_tim.c:3,843 0x80192bc
TIM6_DAC_LPTIM1_IRQHandler() at stm32g0xx_it.c:268 0x8013a6c
<signal handler called>() at 0xfffffff9
HAL_FLASHEx_Erase_IT() at stm32g0xx_hal_flash_ex.c:282 0x8017682
DoEEP() at EEPromMgr.cpp:323 0x800208c
DoWrite() at EEPromMgr.cpp:280 0x8001f4e
DoEEProcess() at EEPromMgr.cpp:217 0x8001dfc
main() at main.c:614 0x80136f6
Solved! Go to Solution.
2025-05-24 2:33 PM - edited 2025-05-28 7:29 AM
Debug the Hard Fault normally, determine WHAT it is complaining about, the code or the addresses being referenced.
For example unwritten FLASH.
Perhaps have a handler that outputs register and processor state.
https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c
The Writes to flash will briefly stall the MCU, the Erase more so, but stuffs wait-states to achieve this, and shouldn't cause it to fault. The EEPROM Emulation basically journals the writes, so only periodically erases when resources are all consumed.
2025-05-24 2:33 PM - edited 2025-05-28 7:29 AM
Debug the Hard Fault normally, determine WHAT it is complaining about, the code or the addresses being referenced.
For example unwritten FLASH.
Perhaps have a handler that outputs register and processor state.
https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c
The Writes to flash will briefly stall the MCU, the Erase more so, but stuffs wait-states to achieve this, and shouldn't cause it to fault. The EEPROM Emulation basically journals the writes, so only periodically erases when resources are all consumed.
2025-05-25 1:36 AM
As @Tesla DeLorean hinted above, you've probably just erased the FLASH page where HAL_TIM_IRQHandler() resides.
JW
2025-05-25 4:51 AM
I don't think the IRQ handler was in the erased page. I have 2 pages that I erase. Both are at the end of FLASH. The map file shows that no code resides in those two last pages. I've tested this all before and it worked. My knee jerk reaction to seeing the TIM handler called is that the MCU was being asked to execute code when it didn't want to. But I guess thats not true for this MCU right? Even the IRQ get paused during the erase. Which makes the IT based erase not useful and in fact bad for me since I don't know where my main() will be when the erase pause hits..
TIM6 is my WDOG simulator timer set for 7.5ms. It would trigger during the erase. I find it strange however that main is at HAL_FLASHEx_Erase_IT when the fault happens. That is an interrupt based routine. The MCU should have started it, then exited to do other things. I service my WDOG simulator just before this routine gets started.
I'll have to try and reproduce this and check the registers to understand what the fault is.
2025-05-25 8:27 AM
There’s no problem erasing a page on the same bank as you execute. Execution will simply pause until it’s done, doesnt matter where code is. Issue is elsewhere. Follow @Tesla DeLorean advice above. Verify handle being used in tim irq has valid data.
2025-05-25 9:03 AM
Pretty much everything is valid. This code has been working as far as writing. the TIM is working as its running continuously. There is no code for the TIM to execute as its been commented out for weeks while I work on other things.
My suspicion is something didn't quite get cleared when I did a debugger reset. I am keeping my eye on it. If it happens again then I will use Tesla DeLorean's advice to chase down the Hard Fault info. Seems it won't be so easy on the M0+.
I don't have any EEPROM emulation. I have written my own routines. I've made some changes so there will be more control over when this 30ms pause happens.
2025-05-25 10:32 AM
My USART buffer is queueing up writes, but its a diagnostic output so doesn't have all the checks it needs. Its writing 80 bytes past the end of its buffer. My eeprom write queue resides in RAM within those 80 bytes being overwritten...
2025-05-26 5:15 AM
> My eeprom write queue resides in RAM within those 80 bytes being overwritten
Is this explanation/solution of the problem?
JW
2025-05-28 7:23 AM
Yes, that overwrite caused flash to attempt an erase at the wrong location.