Skip to main content
Visitor II
March 3, 2022
Question

STM32G071RB Nucelo board - Can't access MCU via SWD or Serial Bootloader

  • March 3, 2022
  • 2 replies
  • 2149 views

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

    This topic has been closed for replies.

    2 replies

    Graduate II
    March 3, 2022

    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 ...

    S. AliAuthor
    Visitor II
    March 3, 2022

    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

    Graduate II
    March 3, 2022

    I repeat you dont need change option bytes to use serial system bootloader

    Graduate II
    March 5, 2022

    And for your code basic check miss

    HAL_FLASH_OB_Unlock();
     
    	HAL_FLASHEx_OBProgram(&FLASH_Handle);
     
    	HAL_StatusTypeDef status = HAL_FLASH_OB_Launch();
     
    	HAL_FLASH_OB_Lock();
     
    	if (status != HAL_OK) {

     same for get obstruct.