Hi everyone, Has the factory bootloader any reason to do a soft reset before any command is received ?

[JeremyH1]

I'm trying to use the factory bootloader from STM32l486 microcontroller without success. From the application code, the MCU jumps to the bootloader code located at beginning of the system memory using the following piece of code adapted from what I've seen in several posts. But everytime the microcontroller jumps to the bootloader, it's reseted.

• I can confirm the jump to the bootloader code using instruction stepping mode, I can see that PC and SP make their life in the system memory
• Using a debugger, setup to break on reset handler entry, I can see in the RCC_CSR register, that reset has been caused by a software reset. Boot0 pin is pulled-down so the MCU resets on the flash memory containing my application.

void JumpToBootloader(void)
{
	void (*SysMemBootJump)(void);
 
	/**
	 * Step: Set system memory address according to AN2606 (Bootloader 0xA3 implementing USART V3.1)
	 */
 
	volatile uint32_t addr = 0x1FFF0000 ;
 
	/**
	 * Reset UART peripheral
	 */
	__HAL_RCC_USART1_FORCE_RESET();
	HAL_Delay(5);
	__HAL_RCC_USART1_RELEASE_RESET();
	HAL_Delay(5);
 
	/**
	 * Stop all peripherals clocks
	 */
	alpmStopAllClocks();
 
	/**
	 * 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.
	 */
 
	 __DSB();
	__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();    //Call HAL macro to do this for you
	__DSB();
	__ISB();
 
	/*
	 * Set vector table location to beginning of remapped system memory
	 */
	 SCB->VTOR = 0;
 
	/**
	 * 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();
 
	while (1) {}
}

 Thank you for your help,

Jeremy

[Tesla DeLorean]

__disable_irq(); // ?? FFS

Nobody on the other side of worm-hole enables this again, sure you need this if you've turned all your peripheral sources off?

The loader can use a watchdog, this will reset. The loader watches multiple interfaces, any noise on the monitored pins with be interpreted as a connection with a 0x7F test pattern (USARTs for auto-baud)

[JeremyH1]

In fact, it's very important to disable the interrupts before jumping to the bootloader, but not all the interrupts using disable_irq(), instead every interrupt one by one using HAL_NVIC_DisableIRQ(...). I assume the bootloader reenables all interrupts for the needs of systick handling.

In my case, by reading the beginning of the system memory, I've figured out most of the interrupt vectors point to the same address in the system memory. I've put a breakpoint at this address, which seems to be a bootloader default interrupt handler. Bingo, the debugger breaks into just before resetting. By reading the ICSR register, I've retrieved the vector number which corresponds to the USART1 interrupt. So I've disabled the USART1 interrupt on which I was sending the "7F" magic pattern, and everything is OK now.

Thank you for help,

Jeremy