Hi,
MCU version 20KB RAM, 128 KB FLASH category 5. I tried solutions on the web available for different STM32 MCU with no success. BOOT0 pin is fixed to GND in my custom PCB.
My final code flow is like below:
1)Reset Handler
2)System init MSI as a system clock, reset all other clock settings and does something like below
SCB -> VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector table relocation in Internal Flash*/
3) Main Function
int main(){ HAL_RCC_DeInit(); Systick -> CTRL = 0; Systick -> LOAD =0; Systick -> VAL =0; __disable_irq(); HAL_FLASH_Unlock(); void (*foo)(void) = 0x00000004; __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH(); SCB -> VTOR = 0; __set_MSP(0x20005000); foo(); while(1); }
When i debug, code jumps to the location 0x00000004 but after some instructions device jumps again to reset handler.
Can you correct me to make embedded USBDFU bootloader work ?
Thanks in advance,
void (*foo)(void) = 0x00000004; __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH(); SCB -> VTOR = 0; __set_MSP(0x20005000); foo();
You need to remap SYSTEM Flash to 0 first You need the value AT address 4 (after remapping) as the function pointer, not the value 4.
Note:
MSP is probably just fine, but it would normally use the value at 0x00000000 after the remapping.
>>I tried solutions on the web Mixing up random ideas you copy and paste is not programming. Read the manuals and understand what you are doing.
You must enable the SYSCFG clock before you can remap memory
You should not __disable_irq(), no one enables it again. Turn OFF the interrupts in ALL the peripherals where you have enabled them.
Four is NOT executable code, it contains a 32-bit data word describing where the code is, you should read the word.
The value read needs to occur AFTER the remapping for the ROM data to be at zero
I don't have an L072 to hand but this is a more cogent expression of what you need
#define ROMBASE 0x1FF00000 typedef void (*pFunction)(void); pFunction romboot = (pFunction) *((uint32_t *)(ROMBASE + 4)); // The content __HAL_RCC_SYSCFG_CLK_ENABLE(); SCB->VTOR = ROMBASE; __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH(); __set_MSP(0x20005000); // Arguably *((uint32_t *)(ROMBASE + 0)) romboot();
Having spent some time talking to ST Support about this I found this is a "Feature" of the ST Bootloader mechanism. Always at reset and if you jump to the bootloader by what ever method you choose, it will first read the sampled state of boot0 pin. If 1 the bootloader code continues to run and accepts commands as per the specification. If boot0 pin 0 (which it will be if you are jumping to the bootloader from your application) then it does the bank checks and jumps straight to them if they are valid. I.e. it restarts you application! Probably simplest option is to follow the approaches that use RC network on Boot0 connected to another GPO pin. Otherwise write your bootloader for the second bank and program your application into the first bank.