cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U575 Jump to (FDCAN) bootloader from the application - is the code we use for this purpose correct? is required also code for memory remapping?

RLanz.2
Associate II

We are not sure it really jumps to the bootloader

Please see code attached, especially note if required to add code for memory remapping:

void jump_to_bootloader(void) {
	void (*SysMemBootJump)(void);
 
	/**
	 * Step: Set system memory address.
	 *
	 *       For STM32U575xx, system memory is at 0x0BF90000
	 *       For other families, check AN2606 document
	 */
	volatile uint32_t addr = 0x0BF90000; // STM32U575xx
 
	/**
	 * Step: Disable RCC, set it to default (after reset) settings
	 *       Internal clock, no PLL, etc.
	 */
	HAL_RCC_DeInit();
 
	/**
	 * Step: Disable systick timer and reset it to default values
	 */
	SysTick->CTRL = 0;
	SysTick->LOAD = 0;
	SysTick->VAL = 0;
 
	/**
	 * Step: Disable all interrupts
	 */
	__disable_irq();
 
	// /**
	//  * Step: Remap system memory to address 0x0000 0000 in address space
	//  *       For each family registers may be different.
	//  *       Check reference manual for each family.
	//  *
	//  *       For STM32F4xx, MEMRMP register in SYSCFG is used (bits[1:0])
	//  *       For STM32F0xx, CFGR1 register in SYSCFG is used (bits[1:0])
	//  *       For others, check family reference manual
	//  */
	// //Remap by hand... {
	// SYSCFG->MEMRMP = 0x01; //F7
 
	/**
	 * Step: Set jump memory location for system memory
	 *       Use address with 4 bytes offset which specifies jump location where program starts
	 */
	SysMemBootJump = (void (*)(void)) (*((uint32_t *)(addr + 4)));
 
	/**
	 * Step: Set main stack pointer.
	 *       This step must be done last otherwise local variables in this function
	 *       don't have proper value since stack pointer is located on different position
	 *
	 *       Set direct address location which specifies stack pointer in SRAM location
	 */
	__set_MSP(*(uint32_t *)addr);
 
	/**
	 * Step: Actually call our function to jump to set location
	 *       This will start system memory execution
	 */
	SysMemBootJump();
 
	/**
	 * Step: Connect USB<->UART converter to dedicated USART pins and test
	 *       and test with bootloader works with STM32 Flash Loader Demonstrator software
	 */
}

2 REPLIES 2

>>We are not sure it really jumps to the bootloader

Step the transition with the debugger

>>__disable_irq(); // Step: Disable all interrupts

Not the means to the end. You really want to disable the interrupt you have enabled at the peripherals. Not disable IRQs entirely on the MCU. Nothing on the other side reenables them, they are not disabled at startup normally.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
RLanz.2
Associate II

Thank you for your answer.

  1. Stepping the transition with the debugger, it loses debugger 'connection' somewhere inside HAL_RCC_DeInit(), when stepping in disassembly, around the code which resets HSEBYP & HSEEXT bits, before Clear PLL1ON bit. We just try to communicate with the bootloader from a host computer via FDCAN and get a timeout. So is there any other way we can be sure it jumps to the bootloader?
  2. We use __disable_irq() as part of the jump_to_bootloader() function, in an earlier project of ours, based on STM32F7x CPU and it works jumping to the bootloader and we can communicate with it from a host computer via CAN. What is the reason to act differently in this case?
  3. Is there a need to take care of memory remapping as part of this function?