STM32F437 option bytes programming hangs

[Gary Todd]

Hi,

On startup my STM32F437 application checks whether JTAG RDP level 1 protection is enabled.  If it is not enabled then it enables it, ending with a call to HAL_FLASH_OB_Launch(), which loads option bytes and resets MCU.

This all works fine, except if I load the code from JTAG (using ST-Link or Keil U-LINKPro). In this case HAL_FLASH_OB_Launch() does not restart the MCU, it just seems to hang. If I power-cycle the MCU then the option bytes have been programmed OK.

I have seen a workaround for an STMF466 whereby the code is executed from RAM and put into standby and using WFI to wait for RTC wake-up interrupt (see STM32 Security tips - 4 RDP without POR in STM32F4 (youtube.com)). In my case this does not work. The MCU does not restart.  I have also tried relying on the IWDG to timeout and restart.  This appears to start the reset process but the MCU does not fully restart.

It seems that a JTAG connected at the time of launching the option bytes, requires a h/w reset to restart the MCU.

Has anyone experienced this problem and have a workaround?

Thanks

[Jacob WOODRUFF]

Hi All,

 

This case has been routed to our online support center for direct support. 

 

Regards,
Jake

ST Support

[Bob S]

That is the expected behavior.  RDP level 1 does not allow JTAG/SWD access.  So when you you enable RDP 1 then reboot the MCU, the internal bootloader sees RDP1 and sees attempted JTAG access and halts the CPU to prevent access.  Power cycling is the only way to get out of that state.

[waclawek.jan]

I've just realized that this mechanism (forced processor lockup in case of SWD/JTAG active and RDP1) is why after programming+locking devices using STLink I have to power-cycle them.

One learns every day. Thanks, @Bob S !

JW