STM32L433 stuck in bootloader after updating with CubeProgrammer

[antoinej]

Hi,

 

I have a custom product/board that has an embedded STM32L433. The STM32 is powered with an external battery. It is also connect through USB to a COM board that runs Windows.

 

The COM controls the boot0 and reset pins of the STM32 which allows me to update the chip using CubeProgrammer API. I created a custom application in C# that worked fine until I tried to activate RDP level 1.

 

Since I cannot do a POR, I implemented the activation of RDP in the STM32 software using the enter standby mode method.

 

When I try to update with the RDP already active, I use the connectDfuBootloader2 method with rdu = true. This properly downgrade RDP from level 1 to level 0 and I am able to update the STM32 using the downloadFile method afterward.

 

The issue is that after downloading the new software, the STM32 gets stuck in bootloader. The only way to get it unstuck is to call another time the connectDfuBootloader2 with rdu = true. This does not downgrade the RDP level, it only restarts the STM32 which does not make much sense to me.

 

Do you know why I have to do this and if there is anything I could do to fix this?

 

On a side note, the update works fine when I do it using a ST-Link module when the COM is off (no external power), but behave the same way when using the ST-Link and COM is on.

 

Thank you,

 

Antoine

[STOne-32]

Dear ​@antoinej 

 

May be this article will help on the behavior observed : 

Regards,

STOne-32

[antoinej]

I am not quite sure what I can do with the wiring that I have to prevent the empty check mechanism (if this is the problem).

 

I only have control over the boot0 and nrst pins and I use DFU bootloader to update and manage the STM32.

 

I have tried writing and reading option bytes using CLI to perform a OB_LAUNCH, I have tried using the CLI, but nothing works.

 

The only thing that works is either calling connectDfuBootloader2(rdu = true) or STM32_Programmer_CLI.exe -c port=USB1 -rdu.

 

Did I miss something to prevent the empty check mechanism with the hardware setup that I have? Is there another work around?

 

Regards,

 

Antoine