2021-05-21 03:19 PM
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
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.
Solved! Go to Solution.
2021-05-26 04:23 PM
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.
2021-05-21 04:00 PM
To follow up with more information, I assume that I am able to modify the nBOOT0 at bit 26 at the location 0x1FFF7800
2021-05-22 05:29 AM
You can modify option bytes in firmware via HAL_FLASHEx_OBProgram. nBOOT0 is one of the user configuration options.
You can modify option bytes with the bootloader using the Write Memory command.
2021-05-22 09:24 AM
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.
2021-05-25 08:28 AM
@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?
2021-05-25 08:55 AM
2021-05-25 08:59 AM
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.
2021-05-25 09:13 AM
2021-05-25 09:16 AM
Oh, that may be perfect then. Is there documentation on how to do the write memory command? I think this is the path I expect to use for firmware updates.
2021-05-25 09:18 AM