Skip to main content
Visitor II
December 17, 2025
Question

“STM32L433RCT freezing (lock-up) problem

  • December 17, 2025
  • 2 replies
  • 477 views

Hello,

I am experiencing the following issue with the STM32L433RCT microcontroller I am using: when I pull the NRST pin LOW and then release it to HIGH, the microcontroller does not recover from reset. In this case, power cycling the device does not solve the problem either. However, if I disconnect the battery from the circuit and then reapply power, the device starts up normally.

This issue occurs mostly during the first boot. After the initial startup is successful, even if I reconnect the battery and pull NRST LOW again, the system does not lock up. I am concerned about what would happen in the field if the device were to freeze and could not recover using a reset.

    This topic has been closed for replies.

    2 replies

    Super User
    December 17, 2025

    That chip boots up into the bootloader when flash is empty. Could be what is happening. You will need to do a power cycle after programming the chip to reset the "flash empty" flag. Just toggling NRST will not do it.

    TDK_0-1765985296774.png

     

    Could also be any number of other issues. Is BOOT0 held low or set via option bytes?

     

    Attach a debugger to see where the chip is at and why it's not functioning correctly.

    albfurkanAuthor
    Visitor II
    December 18, 2025

    Hello,

    I have a piece of code where I only toggle an LED inside the main loop. When I connect the debugger and start the code, everything seems to work normally. However, when the debugger is connected and I power the device off and on again, I notice that the LEDs no longer blink. When I check the NRST and BOOT0 pins, I see that NRST = HIGH and BOOT0 = LOW. When I stop the code, it appears to be stuck at a certain point. You can see the point where it gets stuck in the content named “ek1”, and my user configurations are in the other file.

    albfurkanAuthor
    Visitor II
    December 18, 2025

    When I try to debug the code that I normally work with, I get the errors shown in the image.

    Super User
    December 18, 2025

    It looks like the code is in the default handler which means it's in an interrupt that you haven't implemented. What interrupts are enabled in your code?

    You can look at VECTACTIVE field in the SCB registers to see which interrupt it's in. Subtract 16 and compare to IRQn_Type.

     

    > When I try to debug the code that I normally work with, I get the errors shown in the image.

    Address 0x1FFFxxxx indicates the chip is in the bootloader.

    albfurkanAuthor
    Visitor II
    December 19, 2025

    What is the reason that the device stays in the bootloader when it is powered off and on?