Skip to main content
Graduate II
May 24, 2025
Solved

RWW for Single Bank Flash on STM32

  • May 24, 2025
  • 5 replies
  • 760 views

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	
    This topic has been closed for replies.
    Best answer by Tesla DeLorean

    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.

    5 replies

    Graduate II
    May 24, 2025

    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.

    Super User
    May 25, 2025

    As @Tesla DeLorean hinted above, you've probably just erased the FLASH page where HAL_TIM_IRQHandler() resides.

    JW

    Carl_GAuthor
    Graduate II
    May 25, 2025

    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.

     

    Super User
    May 25, 2025

    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.

    Carl_GAuthor
    Graduate II
    May 25, 2025

    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.

    Carl_GAuthor
    Graduate II
    May 25, 2025

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

    Super User
    May 26, 2025

    > My eeprom write queue resides in RAM within those 80 bytes being overwritten

    Is this explanation/solution of the problem?

    JW

    Carl_GAuthor
    Graduate II
    May 28, 2025

    Yes, that overwrite caused flash to attempt an erase at the wrong location.