2022-03-03 06:02 AM
Hi
We have an application where STM32G071RB are used and can only be programmed via ST's Serial Bootloader. That works fine but after 1st programming, we realised that the Boot options bits in the Userbytes of the Flash memory need to be configured correctly to allow for subsequent Serial Bootloader access (these are all set by default):
To achieve that, within our applicaiton firmware, we wrote a code that programs those bits:
nBOOT_SEL to 0
nBOOT1 to 1
nBOOT0 to 0 (Although this will be ignored for the use case)
To boot in Serial boot mode, we set the PA14-nBoot0 pin to logic 1 and this all works perfect - so that's great.
The issue is that after few power cycles (random 5-10), the MCUs do not boot at all - neither in Normal mode to run application firmware, Nor can these be put in Serial bootloader mode. Also, these cannot be access using SWD interface.
For simplicity and to avoid any uncertainties in the custom hardware, we did this exercise on the Nucelo-G071RB and the same issue happens. We now have 2 Nucleo boards whose on board MCUs cannot be accessed via Serial Bootloader or SWD interface, and also these do not boot to run the Application firmware.
Here is the code snippet that we use to write the Boot related option bytes:
// Write required Option bits for Serial Bootloader, otherwise, MCU can only be revived using SWD interface
{
FLASH_OBProgramInitTypeDef OBStruct = {0};
HAL_FLASHEx_OBGetConfig(&OBStruct);
OBStruct.USERConfig = OBStruct.USERConfig & (~FLASH_OPTR_nBOOT_SEL);
OBStruct.USERConfig = OBStruct.USERConfig | FLASH_OPTR_nBOOT1;
OBStruct.USERConfig = OBStruct.USERConfig | FLASH_OPTR_nBOOT0;
OBStruct.OptionType = OPTIONBYTE_USER;
HAL_FLASH_Unlock();
HAL_FLASH_OB_Unlock();
HAL_FLASHEx_OBProgram(&OBStruct);
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
HAL_FLASH_OB_Launch();
}
/* USER CODE END 2 */
Please could you advise on this what could be wrong with these MCUs and more importantly to recover these from this state?
Thanks
2022-03-03 10:10 AM
Why option bytes rewrite? Exist simple way , that jump to system bootloader from application .
Your modification seems create hazard and change OB for example to RDP 2 ...
2022-03-03 10:14 AM
Thanks for your reply. We need to change the option bytes to suit application specific Serial Bootloader entry mechanism.
I can see the hazard in flash/option-byte corruption since these are being written on each Reset (These should only be changed when are not set to desired values). It is not uncommon to change Option bytes in the application firmware.
The question now also is how to recover these MCUs
2022-03-03 10:18 AM
I repeat you dont need change option bytes to use serial system bootloader
2022-03-03 10:41 AM
Could you please explain why not? We have to be able to put MCU in serial bootloader mode externally (not from within the Application firmware) and also the Virgin MCU should be serially bootloadable.
This is what the default MCU configuration is:
With these bits set, the BOOT0 pin cannot be used to put the MCU in bootloader mode (once its application flash area is non empty) because:
2022-03-03 11:12 AM
We have to be able to put MCU in serial bootloader mode externally
your words is false, because change nBOOT on every reset isnt externaly.
Simply in normal main code first line
if{ any gpio marker ) jump_to_system();
I for example use this and load firmware over Android app and bluetooth module.
2022-03-03 11:22 AM
Thanks for your reply - that maybe an option to use in the future but it doesn't help solve and answer the issue at hand. You asked me the reason for changing option bytes in the code and I have explained that to you. These have a use case that is why ST provide library to access them,
I am looking for help on reviving the non-responsive MCUs and get to the bottom of the reason that caused them into this state.
2022-03-03 11:39 AM
When SWD or JTAG debug isnt possible and no way to erase MCU, i mean try get it back is waste time. You need try and test other method for ...
2022-03-04 03:04 AM
That's not how engineering issues are addressed. We need to find the root cause of the issue to make sure this doesn't happen again. Your suggestion of triggering bootloader from the Application firmware will also require the BOOT_LOCK bit to be programmed in the application firmware (at least once) because by default it is unchecked:
So the original issue and the requirement remains. How to safely write to the option bytes
2022-03-04 07:38 AM
??? how boot ,when you start system loader from app you dont boot .