Skip to main content
Roshan
Associate III
March 22, 2021
Solved

inconsistent watchdog reset

  • March 22, 2021
  • 5 replies
  • 3058 views

Hi all,

I am practicing the Secure boot using SBSFU using the stm32L476 development board. I have implemented a code for the SBSFU, but it is giving a warning

WARNING: A Reboot has been triggered by a Watchdog reset!

      INFO: Last execution detected error was: Watchdog error.

= [EXCPT] WATCHDOG RESET FAULT!

and I define the key for the 0x0000AAAAu, but it gets restarted inconsistently,

for example, as first it will restart in 10 cycles of execution and next it will restart in 100 executions and again in 20 cycles like that, is there any reason behind this. I am really new to the SBSFU.

Thanks.

This topic has been closed for replies.
Best answer by Jocelyn RICARD

Hi Roshan,

ok, so your are following the MOOC :)

I tried to setup again, and didn't see any issue. This is normal as watchdog is updated every 500ms

Now, in the setup you have the tamper activated by default through SFU_TAMPER_PROTECT_ENABLE in app_sfu.h

As the tamper interrupt is not defined in this example, the tamper detection falls to the default interrupt handler which is a while(1) loop.

So, 2 solutions. Either disable tamper detection or connect tamper pin PA0 either to VDD or VSS to avoid floating.

Best regards

Jocelyn

5 replies

Jocelyn RICARD
ST Employee
March 26, 2021

Hello Roshan,

could you please tell if you changed something in the provided SBSFU example and if yes what it is ?

I don't really catch the context of your test

Thank you

Best regards

Jocelyn

Roshan
RoshanAuthor
Associate III
March 26, 2021

Hello @Jocelyn RICARD​,

I face the above-mentioned problem without changing anything in the code. But then I change the delay and added a counter to search for any pattern in the watchdog reset, but still, the output gives the same watchdog reset.

Jocelyn RICARD
ST Employee
March 26, 2021

Hello Roshan,

Could you please check the option bytes on your board using the STM32CubeProgrammer.

One option bytes allows activation of IWDG at boot up.

You can use the CLI of this tools like this on a STM32L476

STM32_Programmer_CLI.exe -c port=swd -ob displ

...

OPTION BYTES BANK: 0

  Read Out Protection:

   RDP     : 0xAA (Level 0, no protection)

  BOR Level:

   BOR_LEV   : 0x0 (BOR Level 0, reset level threshold is around 1.7 V)

  User Configuration:

   nRST_STOP  : 0x1 (No reset generated when entering Stop mode)

   nRST_STDBY  : 0x1 (No reset generated when entering Standby mode)

   nRST_SHDW  : 0x1 (No reset generated when entering the Shutdown mode)

   IWDG_SW   : 0x1 (Software independant watchdog)

   IWDG_STOP  : 0x1 (IWDG counter active in stop mode)

   IWDG_STDBY  : 0x1 (IWDG counter active in standby mode)

   WWDG_SW   : 0x1 (Software window watchdog)

   BFB2     : 0x0 (Dual-bank boot disable)

   nBOOT1    : 0x1 (Boot from Flash if BOOT0 = 0, otherwise system memory)

   SRAM2_PE   : 0x1 (SRAM2 parity check disable)

   SRAM2_RST  : 0x1 (SRAM2 is not erased when a system reset occurs)

  PCROP Protection (Bank 1):

   PCROP1_STRT : 0xFFFF (0x807FFF8)

   PCROP1_END  : 0x0 (0x8000000)

   PCROP_RDP  : 0x0 (PCROP zone is kept when RDP is decreased)

  Write Protection (Bank 1):

   WRP1A_STRT  : 0xFF (0x807F800)

   WRP1A_END  : 0x0 (0x8000000)

   WRP1B_STRT  : 0xFF (0x807F800)

   WRP1B_END  : 0x0 (0x8000000)

OPTION BYTES BANK: 1

  PCROP Protection (Bank 2):

   PCROP2_STRT : 0xFFFF (0x80FFFF8)

   PCROP2_END  : 0x0 (0x8080000)

  Write Protection (Bank 2):

   WRP2A_STRT  : 0xFF (0x80FF800)

   WRP2A_END  : 0x0 (0x8080000)

   WRP2B_STRT  : 0xFF (0x80FF800)

   WRP2B_END  : 0x0 (0x8080000)

Best regards

Jocelyn

Roshan
RoshanAuthor
Associate III
March 29, 2021

Hello @Jocelyn RICARD​ 

I have checked all of the option bytes and everything is as you mentioned, not a single element is changed.

still, this showing the reboot has been triggered by the watchdog as I mentioned earlier.

I am using Ymodem to send the .sfb file using teraterm, which is built by simpleApp v2

Thanks

Roshan

DavidAlfa
Senior II
March 26, 2021

If you are debugging, remember to enable watchdog freeze on core halt, or it will overflow when you stop the core and reset.

__HAL_DBGMCU_FREEZE_IWDG();

Roshan
RoshanAuthor
Associate III
March 29, 2021

hello @DavidAlfa​ 

Thanks a lot, for the reply, I will keep in mind that when I'm doing debugging.

Thanks

Roshan

Jocelyn RICARD
ST Employee
March 29, 2021

Hi Roshan,

First coming back to original post, I'm not sure what you mean when saying ". I have implemented a code for the SBSFU" and "I define the key for the 0x0000AAAAu,".

Can you confirm you took X-CUBE-SBSFU package, compile the L476 example ?

Can you confirm you followed the steps as described in video number 2 of security MOOC part 6 in the following link ?

https://www.youtube.com/playlist?list=PLnMKNibPkDnGd7J7fV7tr-4xIBwkNfD--

Best regards

Jocelyn

Roshan
RoshanAuthor
Associate III
March 29, 2021

Hi @Jocelyn RICARD​ 

yes, I did everything

Thank you for the video. even I was using the same MOOC. I followed every step in part 6 - video 2 and video 4, I wanted to tell you that I have set the KEY_RELOAD to 0x0000AAAAu as mentioned in video 4, and also I am getting the same output as video 4 (25th minute onwards), but if I run it around 2 -10 minutes I am getting watchdog reset error which I mentioned earlier and I can't find any pattern of this resetting. so this was my problem. I hope you understood.

Thanks

Roshan

Jocelyn RICARD
Jocelyn RICARDBest answer
ST Employee
March 29, 2021

Hi Roshan,

ok, so your are following the MOOC :)

I tried to setup again, and didn't see any issue. This is normal as watchdog is updated every 500ms

Now, in the setup you have the tamper activated by default through SFU_TAMPER_PROTECT_ENABLE in app_sfu.h

As the tamper interrupt is not defined in this example, the tamper detection falls to the default interrupt handler which is a while(1) loop.

So, 2 solutions. Either disable tamper detection or connect tamper pin PA0 either to VDD or VSS to avoid floating.

Best regards

Jocelyn

Roshan
RoshanAuthor
Associate III
March 29, 2021

Hi @Jocelyn RICARD​ 

Thank you for your valuable time, I will do it. furthermore, I found out that I work in a noisy environment and that could also lead to this problem.

furthermore, I have a question, for the firmware update we are normally using the Blue push button to get open the YModem protocol, for that can't I use another pin, is it so how can I map it.

Jocelyn RICARD
ST Employee
March 29, 2021

Hi Roshan,

the triggering of update is 100% up to your implementation.

SBSFU is an example code that is supposed to be adapted to your constraints.

First, the update can be done either by application (in case of 2 image) or by the bootloader internal loader, or by a standalone loader (specific application launched by SBSFU).

If you want to use the loader embedded in SBSFU, you can trigger this by an GPIO or even "logically" from your application.

By logically, I mean use a way to communicate to SBSFU that on next reset it will switch to update mode.

This can be done for instance using a specific RAM or backup SRAM location that is filled with a magic by application.

At next reset SBSFU detects this magic value and starts the update.

Such mechanism is provided in the STM32WB example

Best regards

Jocelyn