2021-05-16 04:17 AM
Hi
I'm trying use In App programming for the STM32L432KC board. Unfortunately there is no working example provided (app note AN4657 has STM3210C_EVAL and STM32L476G_EVAL which is dual bank).
I have managed to modify the example and written correctly the Flash (verified with debugger). The problem is when jumping to the address I get a hardfault_handler error.
The details of my setup are these:
I have separated flash in 2 areas since I don't have dual banks
area A 0x0800 0000
area B 0x0802 0000
I write my new binary (blink code) file in area B and I jump using the following code, where APPLICATION_ADDRESS=0x0802 0000 (area B):
//SCB->VTOR = APPLICATION_ADDRESS;
/* execute the new program */
JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);
/* Jump to user application */
JumpToApplication = (pFunction) JumpAddress;
/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);
JumpToApplication();
I read in this post that you need to add SCB->VTOR = APPLICATION_ADDRESS; for the interrupt vectors to initialize to the new address but I still get the error
inside the hardfault_handler I read the SCB and get the following
which gives a BFSR register error at address 0x20010000 which points to a reserved space
Any ideas what I'm doing wrong ? According to the example you don't need to do anything else after you have loaded new program to flash. Just set MSP and jump.
Thanks in advance
2021-05-16 10:12 AM
Hmm with this i dont help you only
FLASH (rx) : ORIGIN = 0x8020000, LENGTH = 256K
isnt right, right is for B code
FLASH (rx) : ORIGIN = 0x8020000, LENGTH = 128K
for A code
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
on some situation too RAM need split , but this seems not be your trouble now.
You have some other mistake .
And for perfect report you can have one PIC code bin and two tables then
BINA = TABLEA + PICCODE
BINB = TABLEB + PICCODE
or load table from one bin to ram and recalculate all address before relocate.
but better is use normal compilator ways to work... And too normal IAP work with loader part and APP part and not twoo APP parts
2021-05-16 10:22 AM
Fixed that too Thanks :) It still stops at some point later (0x8020a0a) but at least we made some progress.
2021-05-17 02:33 AM
The fact that I get 0x8020a0a at the disassembly should be good which means that jump has succeeded but how can I debug further ?
I can't understand what the assembly is doing and can't see C code.
Is there a way to put a breakpoint at the beginning of my new loaded code?
2021-05-17 03:21 AM
Found it. I needed to re-enable IRQs in the loaded app (blink).
Question is why didn't blink crash before without this line ? Isn't the init of the code the same when uploading via debugger or via IAP ?
Wasted so many hours for a few details that could have been written in the app note. Really frustrating