2022-08-29 03:21 AM
Hello,
I am currently writing a program that will delete the bootloader, which is stored in 24 flash pages (Bootloader begins at 0x08000000, the program itself begins at 0x800C000).
Pages 1-11 & 13-23 can be easily erased. Now the problem is, the page 0 and 12 cannot be erased without error.
Code goes like this (same for page 12):
flash_erase(0,1);
from flash_erase() into -->
HAL_FLASH_Unlock();
HAL_FLASHEx_Erase(&erase_param, &err) //erase_param contains the right page and bank
from HAL_FLASHEx_Erase(&erase_param, &err) into -->
FLASH_PageErase(page_index, pEraseInit->Banks);
/* Wait for last operation to be completed */
status = FLASH_WaitForLastOperation((uint32_t)FLASH_TIMEOUT_VALUE); //
That's where the program gets stuck. The page erase still worked, I can see it in the device memory. But there's this error that I can't track down any further.
This is the debug call stack:
Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)
0xfffffffe
<signal handler called>() at 0xfffffff1
0xfffffffe
<signal handler called>() at 0xfffffff9
HAL_FLASHEx_Erase() at stm32l4xx_hal_flash_ex.c:197 0x800fc4a
flash_erase() at flash.c:201 0x8015cb8
app_process() at sulpom_app.c:227 0x8015738
main() at main.c:121 0x800ce84
While debugging, I noticed that if I step into the function
FLASH_PageErase(page_index, pEraseInit->Banks)
the program does not get stuck and the flash pages are erased properly.
Can somebody help me find the cause of this error and help find a solution? Thank you all.
Best regards
EDIT: STM32L452
Solved! Go to Solution.
2022-08-29 05:56 PM
Got very little actual detail to work from.
Piranha's suggestion about SCB->VTOR would be worth checking, the ST code uses a pretty poor implementation in SystemInit(), reliant on #defines rather than linker symbols. Make sure it points to 0x0800C000, or whatever your application base is.
Check the boot loader doesn't leave Systick and other interrupts running.
If you've got a functional serial port you could printf status and register content,and things like SCB->VTOR
2022-08-29 03:30 AM
In the usual case is RDP enabled?
What STM32 are we talking about?
Have you instrumented code to understand behaviour without debugger attached?
2022-08-29 03:50 AM
How can I check, if RDP is enabled?
By your second question, you mean something like an LED blinking throughout the erasing process right? If so, no I did not do that yet.
2022-08-29 04:10 AM
LEDs are far less helpful than say UART output of specific details and register content, etc
Look at option bytes related to read protection and write protection.
2022-08-29 04:20 AM
RDP is level 0, so no protection.
What can I do from here on?
2022-08-29 04:52 PM
Probably the SCB_VTOR register is set to the beginning of the flash memory in page 0. An interrupt happens and executes a code located at page 12.
> I am currently writing a program that will delete the bootloader
That is a nonsense. If the power is cut off, your device is bricked.
2022-08-29 05:56 PM
Got very little actual detail to work from.
Piranha's suggestion about SCB->VTOR would be worth checking, the ST code uses a pretty poor implementation in SystemInit(), reliant on #defines rather than linker symbols. Make sure it points to 0x0800C000, or whatever your application base is.
Check the boot loader doesn't leave Systick and other interrupts running.
If you've got a functional serial port you could printf status and register content,and things like SCB->VTOR
2022-09-06 03:17 AM
Thank you for your help! Setting the SCB->VTOR to the application base did the trick.
I should have mentioned that the bootloader will of course be replaced in this procedure.
2022-09-06 03:23 AM
Thank you for helping me out!
Setting the SCB->VTOR to the application base did the trick.
2022-09-06 05:04 AM
The power can be cut off during the update process - between the start of flash erase and the end of programming new code.