How can the nBOOT0 pin be modified via a UART connection. I am using the STM32G071 chip

[VWied.1]

Hello,

I am looking to be able to do in-the-field firmware upgrades with the STM32G071 board. I have used the STMCubeProg tool to be able to modify the nBOOT0 user bit with the ST-Link built into the NUCLEO board.

What I am looking to do is

• to modify nBOOT0 to 0 through the firmware on the device.
• Then I am assuming that I can reset the device,
• and then using a connected UART comms, I can update the firmware,
• After that, I can set the nBOOT0 pin back to 0.

The issues are that I can't figure out how to modify the nBOOT0 bit in the firmware. Also, I am unsure if my STM32G071 will be able to flip its nBOOT0 pin back itself after the firmware update.

I have read through the AN2606 and AN3155 and cannot find an answer to my question. Everything points back to the STM32Prog tool which I don't want to have to rely on.

[VWied.1]

To follow up with more information, I assume that I am able to modify the nBOOT0 at bit 26 at the location 0x1FFF7800

[TDK]

You can modify option bytes in firmware via HAL_FLASHEx_OBProgram. nBOOT0 is one of the user configuration options.

https://github.com/STMicroelectronics/STM32CubeG0/blob/5cb06333a6a43cefbe145f10a5aa98d3cc4cffee/Drivers/STM32G0xx_HAL_Driver/Inc/stm32g0xx_hal_flash.h#L95

You can modify option bytes with the bootloader using the Write Memory command.

[Piranha]

Option bytes are stored in FLASH memory and will eventually wear out... But one can just do a software jump to a system bootloader. There are plenty of information around for doing this.

[VWied.1]

@TDK​ Thank you for hitting my first bullet point of modifying the nBOOT0 bit to get to the bootloader. What I am unclear about now is how do you get out of bootloader mode after the firmware update is complete? Will the STM32 MCU automatically set the nBOOT0 bit back to 0 after the firmware update is complete?

[TDK]

It wont change nBoot0 on its own. You need to do that if you want it to change.
Using a software jump to the bootloader is the better option here in my opinion, leaving option bytes alone.

[VWied.1]

The only issue I can see with the Software jump is that what happens if power gets pulled in the middle of the firmware update. In that case, it will have a corrupted firmware image and not be able to recover. Because of this, it will not be able to jump back to the bootloader ever and will remain bricked. Is that an accurate statement?

Is there any way to set nBoot0 outside of the firmware through the UART communication with a special bootloader command? There will be a connected embedded Linux chip that will be issuing the firmware update via the UART comms and would be able to request a change to the option bytes.

[TDK]

Sequence should be:

 HAL_FLASH_Unlock();
 HAL_FLASH_OB_Unlock();
 HAL_FLASHEx_OBProgram(&ob_cfg);
 HAL_FLASHEx_OB_Launch();

The last function causes a reset which makes the option bytes active. It doesn't matter what code you have after this because the mcu resets, but I would still monitor the return value.

The reference manual goes over the sequence needed to perform these steps. You can also look at the source to find out what HAL is doing. For example:

/**
 * @brief Launch the option byte loading.
 * @retval HAL Status
 */
HAL_StatusTypeDef HAL_FLASH_OB_Launch(void)
{
 /* Set the bit to force the option byte reloading */
 SET_BIT(FLASH->CR, FLASH_CR_OBL_LAUNCH);
 
 /* We should not reach here : Option byte launch generates Option byte reset
 so return error */
 return HAL_ERROR;
}

It makes sense that this returns HAL_ERROR. The first statement, which would normally reset the chip, doesn't work because the option bytes are locked.

If you find checking for return values a pain, consider defining a macro:

#define RUN_HAL(x) if ((x) != HAL_OK) {while (1);}
 
...
 
RUN_HAL(HAL_FLASH_Unlock());

At least that way you have a chance of catching errors when they happen, instead of having to hunt them down afterwards.

[VWied.1]

That was it, thank you.