cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Programmer CLI Bootloader Procedure

CMill.3
Associate

I am using an STM32L452 Nucleo-64 dev kit. I am trying to use the bootloader to update firmware on it. My understanding is that you can set flash option bits in order to enter system memory (bootloader mode) on reset, and this does seem to work. I am able to successfully flash the MCU via the STM32CubeProgrammer interface. But when I try to use the command line version of the Cube Programmer, sometimes the download command is not executed and I get a NACK response, and sometimes I do see the progress bar reach 100%, but the MCU stays in bootloader mode. If I reset the board using the reset switch on it, it will just revert to the previous program instead of the one that was supposed to be flashed (it is not being fleshed properly). When I use the Cube Programmer UI, I can see that the firmware is successfully updated. I need to use the CLI version for our product though. I am flashing the MCU over UART1, and this works in the UI version. I am wondering if this problem has to do with the flash option bit manipulation? Any other ideas? I have attached a screen shot of the command line and a log file from the CubeProgrammer. Please see below for option bits code. Thank you.

void configureBoot(){

 while((FLASH->SR & FLASH_SR_BSY_Msk) == FLASH_SR_BSY_Msk ); // wait while flash operation busy (BSY is set)

 FLASH->KEYR = 0x45670123; // set Flash key to allow writes to FLASH_CR

 FLASH->KEYR = 0xCDEF89AB;

 FLASH->OPTKEYR = 0x08192A3B;// set Flash optkey to allow writes to FLASH_OPTR

 FLASH->OPTKEYR = 0x4C5D6E7F;

 FLASH->OPTR &= ~FLASH_OPTR_nSWBOOT0_Msk; //nBoot0_SW bit 0

 FLASH->OPTR |= FLASH_OPTR_nBOOT1_Msk ; // nBoot1 bit 1

 FLASH->OPTR &= ~FLASH_OPTR_nBOOT0_Msk ;// nBoot0 bit 0

 FLASH->CR |= FLASH_CR_OPTSTRT_Msk; // Set OPSTRT

 while((FLASH->SR & FLASH_SR_BSY_Msk) == FLASH_SR_BSY_Msk ); // wait while flash operation busy (BSY is set)

 FLASH->CR |= FLASH_CR_OBL_LAUNCH_Msk; // system reset

}

1 ACCEPTED SOLUTION

Accepted Solutions
CMill.3
Associate

This issue was resolved by using the command -"ob nBOOT0 = 1". Reconfiguring the flash option bits allows the user to choose which memory location to run on boot (main flash, system(bootloader), or sRAM). The MCU needs to be reset after programming option bytes to load them. The program in the specified memory location will start running after entering the -ob command. Also, I am not externally driving the BOOT0 pin here. This is all done with the software.

View solution in original post

1 REPLY 1
CMill.3
Associate

This issue was resolved by using the command -"ob nBOOT0 = 1". Reconfiguring the flash option bits allows the user to choose which memory location to run on boot (main flash, system(bootloader), or sRAM). The MCU needs to be reset after programming option bytes to load them. The program in the specified memory location will start running after entering the -ob command. Also, I am not externally driving the BOOT0 pin here. This is all done with the software.