2016-05-05 03:37 AM
Hey guys, my first step in creating a bootloader was simply to move the app (which resided at 0x8000000 to 0x8020000 through the linker file. Next, I created a basic bootloader at address 0x8000000 which basically does this:
__disable_irq();__HAL_RCC_SYSCFG_CLK_ENABLE();SYSCFG->MEMRMP=1;__set_MSP(*(__IO uint32_t*) (0x8020000)); (pFunction)=( void(*)(void)) (*((uint32_t *) (0x8020000 + 4)));SCB->VTOR = 0x8000000 + 0x20000; So far, this seems to work as I can step through my application code, I can see it start at 0x800 and then jump to 0x802 and then my software units begin to go through their init. What doesn't work is when my application hits HAL_Delay(), it just spins forever....Does this imply my clock is not running or interrupts are disabled? Its odd to me because I am calling my application init functions so I know I am setting up the micro ok, but once I move it to 0x8020000, it doesn't work....Any ideas? #stm32f427-boot2016-05-05 03:45 AM
The syscfg stuff seems unnecessary,and you'd need to enable the irq on the other side somewhere.
2016-05-05 03:50 AM
If I take my app and move it back to 0x800 (thus writing over the booloader), the system works fine, the app boots completely, so to me, it would seem that I must be enabling interrupts right? I shouldn't need to change anything in my app, outside of relocating it to 0x802
Added note: I am using FreeRTOS in my application so does/could it be doing something to the addresses?2016-05-05 05:08 AM
I think I solved it...
Within system_stm32f4xx.c there is a line of code that reads:SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSETFLASH_BASE is defined as 0x8000000...I changed this to 0x8020000 and it works ok. FLASH_BASE is located in Drivers\CMSIS\Device\ST\STM32F4xx\Include.Was worried about changing core files, but it works...2016-05-05 05:33 AM
system_stm32f4xx.c is a board/project specific file that you modify to match your hardware and configuration.
You shouldn't need to reinitialize the clocks and PLLs either, as your loader has those setup already. From an RTOS you need to be careful not to transfer control via an interrupt, or in a user state.