2014-11-12 11:13 PM
I have a requirement for firmware upgrade. I am planning to use USB DFU class. But command for firmware upgrade will come from PC application in my case . so i need to switch to bootloader which is there in System Memory. As initially i am running application so it is getting booted from User flash i.e i have Boot0 and Boot 1 pins configured for User flash. As DFU bootloader is there in System flash ,now for that Boot0 and Boot1 pins settings need to be changed . is there a way like Boot 0 and Boot 1 settings remain same as User Flash memory and in the application we jump to System Memory and use DFU for upgrading the firmware?
#stm3220g-eval #stm32f207-flash2014-11-12 11:44 PM
2014-11-13 01:51 AM
By referring to the video Calling the STM32 SystemMemory Bootloader from your application i am using the below mentioned code. This code gets executed but still Dfuse application does not detects the STM device in DFM mode.
Even PC does not detects USB.void BootLoaderinit(uint32_t BootLoaderStatus){ JumpAddress = *(__IO uint32_t*) (0x1fff0004); JumpToBoot = (SysMemBootJump) JumpAddress; if(BootLoaderStatus == 1) { HAL_RCC_DeInit(); SysTick->CTRL =0; SysTick->LOAD=0; SysTick->VAL=0; __set_PRIMASK(1); /* Initialize user application's Stack Pointer */ __set_MSP(*(__IO uint32_t*) 0x20001000); JumpToBoot(); } while(1); }2014-11-13 11:43 PM
2014-11-14 04:37 AM
Probably because you're not entering in reset conditions. But rather than rehash this all over again.
[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/jumping%20to%20the%20bootloader%20via%20software%20does%20not%20permit%20dfu%20mode&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21¤tviews=232]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2Fjumping%20to%20the%20bootloader%20via%20software%20does%20not%20permit%20dfu%20mode&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21¤tviews=2322016-02-21 11:34 PM
This works for me on a STM32F4 device. Must be called in the beginning of main() based your ''enter bootloader condition'' (magic constant in RAM etc.):
#define BOOTLOADER_START_ADDR 0x1FFF0000
void JumpToBootLoader(){ __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH(); __set_MSP(*(__IO uint32_t*) 0x2001FFFF); void (*bootloader)(void) = (void(*)(void)) *((uint32_t *) (BOOTLOADER_START_ADDR + 4)); bootloader();}2016-02-22 08:29 AM
__set_MSP((__IO uint32_t*) 0x20020000); // 32-bit aligned preferred, will predecrement, pretty sure you want the address, not the data that's at the address
2016-03-01 06:56 AM
Oops, your statement makes sense.
I noticed that the jump works without the __set_MSP call at all. Is it really needed?2016-03-01 08:26 AM
Is it really needed?
It is more apt to succeed. This isn't how I transfer control. Several of the ROMs set the stack up again as part of the start up code. Keil also uses __initial_sp