Program option bytes safely in STM32 MCU | STM32G041F6P6

[arjun.binu]

I aim to set the IWDG (Independent Watchdog) to STANDBY mode to ensure that our MCU remains in that state without being awakened by the Watchdog. To achieve this, I utilized the following command with STM32_Programmer_CLI.exe:
After executing the command, the option bytes bank was appropriately configured as verified below:

STM32_Programmer_CLI.exe  -c port=SWD freq=8000 -ob iwdg_stdby=0x0

After executing the command, the option bytes bank was appropriately configured as verified below:
IWDG_STOP : 0x1 (IWDG counter active in stop mode)
IWDG_STDBY : 0x0 (Freeze IWDG counter in standby mode)
WWDG_SW : 0x1 (Software window watchdog)

I then flashed the firmware in which the STANDBY mode is implemented. I noticed that the IWDG was freezed and MCU continued to stay in the STANDBY mode properly. But when we validated this process in another device, we got to see some issues. It is being noted that firmware data is being written to the MCU flash and being verified properly but only has issues with executing when core is run/reset.


What might have happened with this particular device which is behaving as mentioned above?
Is there a potential issue with the method employed to freeze the IWDG in STANDBY mode?
Could you please suggest a reliable approach to freeze IWDG in STANDBY mode?
Your support on this matter is highly appreciated.

[Pierre_Paris]

Hello @arjun.binu,

Thank you for your question !

Which STM32G0 are you using ?

Q1 : What might have happened with this particular device which is behaving as mentioned above?

A1 : If I resume, you load the same firmware into two STM32G0 and the behavior isn't what you expected on one of them. Have you set also the same option bytes for both ?

Q2 : Is there a potential issue with the method employed to freeze the IWDG in STANDBY mode?

A2 : Had you enable the "Hardware watchdog" feature through the device option bits?  Because you share the WWDG_SW (for Window watchdog) and not the IWDG_SW (for Independant watchdog). According to the Reference Manual, " The watchdog is automatically enabled at power-on, and generates a reset unless the IWDG key register (IWDG_KR) is written by the software before the counter reaches end of count or if the downcounter is reloaded inside the window.". Also, how did you set nRST_STDBY bit ? 

Q3 : Could you please suggest a reliable approach to freeze IWDG in STANDBY mode?

A3 : Using the IWDG_STDBY is a reliable approach. Just know that when the core halted, the IWDG counter either continues to work normally or stops, depending on the configuration of the corresponding bit in DBGMCU freeze register. Have you set DBG_STANDBY in DBG_CR ?

Best Regards,

Pierre

[arjun.binu]

STM32G041F8P6 is our MCU.

Question  If I resume, you load the same firmware into two STM32G0 and the behavior isn't what you expected on one of them. Have you set also the same option bytes for both ?

We have set the option bytes using the below command similarly in the two devices:
STM32_Programmer_CLI.exe -c port=SWD freq=8000 -ob iwdg_stdby=0x0

The full process that we have followed is as shown below:
1. Configure the option bytes with the command mentioned above
2. Perform a firmware write
3. Reset/Run the core to execute the firmware

Only in one device, the core is failing to run the core [Firmware not executing]. The other device continues to operate fine and the core is running.


Question Had you enable the "Hardware watchdog" feature through the device option bits?  Because you share the WWDG_SW (for Window watchdog) and not the IWDG_SW (for Independant watchdog). According to the Reference Manual, " The watchdog is automatically enabled at power-on, and generates a reset unless the IWDG key register (IWDG_KR) is written by the software before the counter reaches end of count or if the downcounter is reloaded inside the window.". Also, how did you set nRST_STDBY bit ? 

Independent watchdog is enabled in the firmware flashed in the process mentioned above. With option bytes, we had only modified the IWDG_STDBY bit to 0.  Rest of the option byte configurations are kept as it is.
Attaching the screenshot of the complete output of option bytes read command.

nRST_STDBY is not changed by us and is still the default value of 0x1.

If you have noticed anything wrong with the way I configured the option bytes, please let us know.

[Pierre_Paris]

Hello @arjun.binu,

Here some points :

• Only in one device, the core is failing to run the core [Firmware not executing]. The other device continues to operate fine and the core is running. -> If you applied the same OB configuration with the same firmware and same hardware constraint, both pieces should act the same. Have you respected Absolute Maximum Ratings specified in DS12993 ? 
• Can you please explain : " the core is failing to run the core " ? At a specific moment ? Before entering in shutdown... What is the cortex status ? Verify with CFSR & HFSR ?
• Also, can you indicate what is the DBG_IWDG_STOP value in DBG_APB_FZ1 register before entering in shutdown ? 
• No, option bytes seems to be configured the good way ! 

Best Regards,

Pierre

[arjun.binu]

Hi @Pierre_Paris ,

If you applied the same OB configuration with the same firmware and same hardware constraint, both pieces should act the same. Have you respected Absolute Maximum Ratings specified in DS12993 ? 

Yes. We have respected Absolute Maximum Ratings.
To understand more about our MCU configuration and our design , please refer to the following documents attached herewith:
1.  Register viewer dump (Register_viewer_dump.txt)
2.  Cortex-M core register dump (Cortex-M_core_register_dump.txt)
3.  STM32CubeIDE project report (STM32CubeIDE_project_report.pdf)
4.  Snapshot of the MCU schematics (MCU_schematics_snapshot.jpg)

Can you please explain : " the core is failing to run the core " ? At a specific moment ? Before entering in shutdown... What is the cortex status ? Verify with CFSR & HFSR ?

I mean the firmware is not executing after we have completed a firmware upgrade. Firmware is getting written to the flash and the same can be verified. But it is not executing even if we use the command line option to run/reset (-rst/-run).

We can only check the core status when MCU is in the halted state. 
To understand the cortex status, i have included the output of -coreReg which shows the Cortex-M core registers.
R0 = 0xFFFFFFFF
R1 = 0xFFFFFFFF
R2 = 0xFFFFFFFF
R3 = 0xFFFFFFFF
R4 = 0xFFFFFFFF
R5 = 0xFFFFFFFF
R6 = 0xFFFFFFFF
R7 = 0xFFFFFFFF
R8 = 0xFFFFFFFF
R9 = 0xFFFFFFFF
R10 = 0xFFFFFFFF
R11 = 0xFFFFFFFF
R12 = 0xFFFFFFFF
SP = 0x20002000
LR = 0xFFFFFFFF
PC = 0x08003A00
XPSR = 0x01000000
MSP = 0x20002000
PSP = 0xFFFFFFFC
PRIMASK = 0x00
FAULTMASK= 0x00
BASEPRI = 0x00
CONTROL = 0x00


Both CFSR and HFSR are read as follows:

CFSR
0xE000ED28 : 00000000

HFSR
0xE000ED2C : 00000000

I hope this helps. Please let me know if you need further information.

Hard fault analyzer output:

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD mode=hotplug -hf
-------------------------------------------------------------------
STM32CubeProgrammer v2.13.0
-------------------------------------------------------------------

ST-LINK SN : 002B00273532511031333430
ST-LINK FW : V3J11M3B5S1
Board : STLINK-V3SET
Voltage : 0.00V
Error: ST-LINK error (DEV_TARGET_CMD_ERR)
2nd connect tentative with frequency (8MHz)
ST-LINK SN : 002B00273532511031333430
ST-LINK FW : V3J11M3B5S1
Board : STLINK-V3SET
Voltage : 0.00V
SWD freq : 8000 KHz
Connect mode: Hot Plug
Reset mode : Software reset
Device ID : 0x466
Revision ID : Rev 1.1
Device name : STM32G03x/STM32G04x
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M0+
BL Version : 0x53

STM32CubeProgrammer Fault Analyzer

Execution Mode : Thread

Error: Fail to analyze Hard fault, cannot read SP register.

Also, can you indicate what is the DBG_IWDG_STOP value in DBG_APB_FZ1 register before entering in shutdown ?

APB_FZ1 0x00000000 read-write @ 0x40015808
DBG_TIM2_STOP 0
DBG_TIM3_STOP 0
DBG_RTC_STOP 0
DBG_WWDG_STOP 0
DBG_IWDG_STOP 0
DBG_I2C1_STOP 0
DBG_LPTIM2_STOP 0
DBG_LPTIM1_STOP 0

[Pierre_Paris]

Hello @arjun.binu,

I appreciate all the documents you gave, please don't hesitate to contact your local FAE for any other support !

I didn't see obvious reason until now but I have some remarks :

• I don't think your issue is coming from IWDG. But if you want to be sure the IWDG is not an issue. You can disable the clock to the counter of IWDG when the core is halted ? Before entering in shutdown mode, you can do this by setting the bit n°12 DBG_IWDG_STOP in the DBG_APB_FZ1 register. (Also, it's not my advise because this is not the issue)
• Also, you configured BOOT_LOCK bit to 0 and nBOOT_SEL, nBOOT0 & nBOOT1 to 1. According to table 8. Boot modes in RM044, your boot area is the Main Flash memory. The Main Flash memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x08000000). In other words, the Flash memory contents can be accessed starting from address 0x00000000 or 0x08000000. Or your register PC = 0x1FFF19A4, that's the system memory at this address. You wan to run your code from flash (in the first PC you gave PC = 0x08003A00) What is at this address ? and when were this registers captured ? It can explained why the firmware isn't executed.
• That brings this third point : How did you upgrade your firmware ? USART, I2C ? Have you consider AN2606 and AN3155? Here is an extract : "When an application is loaded into RAM and then a jump is made to it, the program must be configured to run with an offset to avoid overlapping with the first area used by the bootloader firmware (refer to STM32 product datasheets and to AN2606 for more details about the RAM offset for the used device).".

Best Regards,

Pierre

[arjun.binu]

Hi @Pierre_Paris ,
Thanks for your remarks.
There is a correction in the register PC in my previous message. The register is as shown below and is actually the same as you mentioned that corresponds to the starting address.
PC = 0x1FFF19A4
This is the exact register value when the device is present in the current state which resembles a halt scenario.

We upgrade the firmware via SWD. If that is the case, then is the extract referenced by you in the previous valid? Since it is mentioned in AN3155 which is the application note for USART protocol.

Sharing the coreReg values again that you have requested last week since there was an error while sharing it last.
Please go through the coreReg values.

R0       = 0xFFFFFFFF
R1       = 0xFFFFFFFF
R2       = 0xFFFFFFFF
R3       = 0xFFFFFFFF
R4       = 0xFFFFFFFF
R5       = 0xFFFFFFFF
R6       = 0xFFFFFFFF
R7       = 0xFFFFFFFF
R8       = 0xFFFFFFFF
R9       = 0xFFFFFFFF
R10      = 0xFFFFFFFF
R11      = 0xFFFFFFFF
R12      = 0xFFFFFFFF
SP       = 0x20000E60
LR       = 0xFFFFFFFF
PC       = 0x1FFF19A4
XPSR     = 0x01000000
MSP      = 0x20000E60
PSP      = 0xFFFFFFFC
PRIMASK  = 0x00
FAULTMASK= 0x00
BASEPRI  = 0x00
CONTROL  = 0x00


Looking forward to hearing from you.

[arjun.binu]

Hi @Pierre_Paris ,
I understood the fact that application code is not running since the PC is pointing to an address in the System Memory region instead of the main Flash memory where our application is located.

And this address `0x1FFF19A4` falls within the System Memory region of STM32 microcontrollers. This area typically contains bootloaders, option bytes, and other system-related information.

Interestingly , we have noticed that this deadlock scenario can be recovered when we power cycle the MCU.

Now I have a question, why is the MCU PC pointing to this system memory address only in some of the devices that we have. So far we have observed this at the time of option byte configuration. But I was wondering , Is there any possibility that this will occur at a different time?