Triggering a reset with the reset pin is usually expected to be an event, but what happens when a microcontroller's reset pin stays triggered?

For example, I am working with an STM32F411RE on a peripheral that is only required occasionally. One of our systems engineers wants to keep the nRST pin low, except when we need to use the peripheral instead of entering into one of the available low-power modes. His reasoning is hardware solutions are better than software solutions.

What exactly happens inside the microcontroller in this case? What would be the arguments for/against this?

In our case, we have implemented software on the main system controlling lines to the nRST pin as well as few EXTI capable pins (including Wake-up pin on PA0). The nRST line is currently pulled-up and driven low by the main system when the F411 needs to be reset. The systems engineer was in favor of replacing the PU with a PD and driving the nRST line high when the peripheral is in-use instead of having the peripheral in sleep/standby mode and using a wake-up interrupt.

  • 1
    \$\begingroup\$ I guess that depends on the device in question but on PIC microcontrollers, for example, the active low reset pin has a internal pullup. Keeping it in reset (by pulling the pin low) uses more current trough the pullup then using sleep mode properly... \$\endgroup\$ Commented May 29 at 8:48
  • 3
    \$\begingroup\$ Sleep mode is a hardware solution though. It is merely activated by software. \$\endgroup\$
    – Lundin
    Commented May 29 at 8:50
  • \$\begingroup\$ @lundin pulling nRST down also requires software to drive it high. \$\endgroup\$
    – D.Pod
    Commented May 29 at 9:18
  • \$\begingroup\$ @D.Pod Don't let your systems engineer to pull reset low with resistor and then drive the reset high with another MCU. MCU data sheet has info why it is wrong. \$\endgroup\$
    – Justme
    Commented May 29 at 9:26
  • 1
    \$\begingroup\$ As @Michael said above, STM32 too while held in reset are in Run mode running out of the 16MHz HSI oscillator, with power consumption in several mA, so significantly higher than in the low-power modes (Sleep-Stop-Standby). \$\endgroup\$
    – wek
    Commented May 30 at 8:28

7 Answers 7


A couple of issues:

  • A MCU usually has a default reset setting where all GPIO are set as inputs. This is an advantage in terms of current consumption, but it is a disadvantage in terms of ruggedness and EMC. The best way to deal with unused pins in most applications is to set them as outputs. This is only possible when the MCU is live, so if you keep it in reset, you may need to add a bunch of external passives etc for protection purposes.

  • MCU out of reset and software boot-up times can cause a relatively hefty execution overhead. Depending on your real-time requirements, you might need the MCU to go live with a certain amount of time. We're talking milliseconds rather than microseconds here, so it is very slow in comparison with most external hardware.

  • Another solution might be to just toggle the power to the MCU. Just shut everything down by cutting the power or disabling the voltage regulator.

But it's really pointless to reason about this without project specific details in mind. What jobs are the MCU handling, what peripherals are there, what external hardware is connected to the MCU etc etc.

As for "hardware solutions are better than software solutions" that's an overly generic statement - it is true in some cases and false in other cases. Hardware guys tend to have strange opinions about software overall (for good or bad), due to lack of experience.

  • \$\begingroup\$ Note though, that on STM32 families the current consumption of digital inputs is higher than for setting analog input. That's probably the reason why they changed the default to analog input with the L4 series. \$\endgroup\$
    – Arsenal
    Commented May 29 at 9:29
  • 3
    \$\begingroup\$ Toggling power to the MCU is not a good idea if its I/O lines are connected to other powered logic. It invites latch-up of the MCU. \$\endgroup\$
    – glen_geek
    Commented May 29 at 12:26
  • 1
    \$\begingroup\$ @glen_geek Hence "what peripherals are there, what external hardware is connected to the MCU" \$\endgroup\$
    – Lundin
    Commented May 29 at 12:48
  • \$\begingroup\$ +1 for the last paragraph alone :) \$\endgroup\$
    – psmears
    Commented May 30 at 12:38
  • 5
    \$\begingroup\$ To be fair, software folks tend to have strange opinions about hardware overall as well... \$\endgroup\$
    – Jon Custer
    Commented May 30 at 12:42

If you hold the MCU in the reset state, it will do nothing, but that's not necessarily what you want.

Power-wise, consumption will probably be higher than in the low power sleep states. And of course the MCU has to boot up every time you want to use it, which also burns power and wastes time. If you use the internal oscillator, it also has to start up. So the total power use will be higher than keeping it in sleep mode when not using it.

All pins will be configured as inputs, perhaps with pull-up resistors. The rest of the circuit should be designed to not do something silly while the MCU resets at power-up anyway, so this should be okay. But this means the MCU can't be used to hold outputs to a desired level while sleeping. It can't wake up on a pin change interrupt either. So it leaves many useful features on the table.

For debugging and programming, it is likely to be annoying to have the other CPU reset your microcontroller while you're scratching your head watching the debugger too...


The answer to which is better depends on lots of factors.

In general terms, holding a CPU in reset is perfectly fine: normal behaviour while you wait for power to stabilise etc. And as Hardware Advocate says, you've removed a system from the equation, thus making it simpler. And simpler is certainly going to keep that CPU doing nothing. But check the power conditions closely.

However, if anything changes in your design, you're stuck. Which, ultimately, is the entire reason for software/firmware: flexibility without hardware changes.

Which you choose depends entirely on how much complexity you have elsewhere.


  • Can you design and debug the microcontroller system without the hold-in-reset circuitry?
  • Is the software system simple enough you're certain you'd be in sleep mode when you're supposed to be?
  • Is there a halfway-house, where perhaps the do-nothing signal from hardware is on an interrupt pin instead of reset. Then you make the get-into-wait-mode the best tested and simplest code you can.
  • What's the downside of the CPU crashing? Any health/safety/danger on the outputs?

It's just the usual set of tradeoffs. Myself I'd lean towards an interrupt pin in general terms if I really wanted hardware signal. Most usually I'd just code in firmware in the most obvious way I could.


Asserting RESET causes (to name a few):

  • All registers throughout the entire microcontroller to be set to their default values. Coming out of RESET requires rebuilding the operational configuration.
  • RESET may disable the oscillators. The system must wait for them to stabilize when restarting them. Some sleep modes can leave them running. Coming out of RESET may use low precision internal RC oscillators. The clock tree must be rebuilt in its entirety before anything else can function.
  • The pins to external peripherals are set to their default state and must be configured to their operational state coming of of RESET.

All this takes time.

Sleep modes allow for system configuration to remain.

  • Depending on power requirements, the oscillators can be left running to maintain precision and accuracy.
  • External pins and communications (example SPI) remain ready for action.
  • Important events can wake-up from sleeping, but not from RESET.

Whether to use SLEEP or RESET requires careful consideration of application constraints.


nRST on STM32 and probably most other microcontrollers is level sensitive and not edge sensitive. So the microcontroller will stay in reset until the pin is released.

This will lead to all registers being reset to their default value (except the reset flags in the RCC_CSR register and registers in the backup domain) and of course no program execution. The pins will revert to their configuration in reset, which is mostly digital inputs (for the F4, it varies with families), but some are also output per default.

Is your system designed in a way, that all lines are not floating which are used as output during the microcontroller being active? Floating lines might cause issues with EMC or excessive current draw inside the inputs.

I haven't tested it myself, so this is only speculation, but the microcontroller might use more power in reset than if put to a low power mode with a different pin configuration. If energy usage is a concern, test this, should be fairly straight forward.

It'll probably take longer to start your program from a reset than from a low power mode - but that is very dependent on your program. That might be an issue, depending on your timing constraints.

A STM32F4 sounds quite beefy for being kept in reset most of the time - is this the most effective solution?


There are other answers that cover some very good points.

I'm not familiar with STM32 parts, but I understand that some parts (eg ATmega328) actually draw more current in RESET than in the some of the sleep/idle modes. This is due to the ISP peripheral (in-circuit serial programming) being active. Which on its own might cause issues if data is seen on the ISP lines while the processor is in RESET.

I would hope that the datasheet would identify cases like this, but I always keep the mindset that a processor in RESET isn't always doing nothing.


Keeping the reset pin low means you are asserting the reset pin and causing the MCU to be reset continuously. This causes constant resets whenever the MCU is powered on. Disabling the MCU by keeping the Reset pin low is bad design and perhaps your systems engineer has bad system requirements or hasn't really explored all features of your MCU. Everything can be software controlled in an MCU and in distributed MCUs. The reason for using MCUs is that you dont have to be fixed in your features as in an IC or ASIC. Don't let hardware interfere unless its the user who wants to change the functionality of the system by pressing a power or reset button. Many MCUs have low power modes in which the awake mode can be triggered when in low power mode with a level change on a pin. Check your MCU to have such feature rather than keep it in reset state unless it is necessary.

  • 1
    \$\begingroup\$ "This causes constant resets whenever the MCU is powered on." – Does it really? My understanding is that asserting the reset pin causes the MCU to enter the reset state, and then it simply remains in that state as long as that pin stays asserted. What are the "constant resets" that you're talking about? \$\endgroup\$ Commented May 30 at 1:42
  • \$\begingroup\$ MCUs reset automatically when they detect a reset pin assert. This causes a non maskable interrupt with the highest priority which resets the CPU. Most MCUs are configured for this type of reset. \$\endgroup\$
    – Amit M
    Commented May 30 at 2:45
  • \$\begingroup\$ @AmitM As I understand it, on most MCUs the reset pin causes the reset state as Tanner described. The reset state clears most registers and sets the program counter to the first instruction, so that when reset is de-asserted, normal execution begins there. It is different from a non-maskable interrupt. \$\endgroup\$ Commented May 31 at 10:34
  • \$\begingroup\$ The reset pin does all the above you described. It would be like the CPU is resetting whenever it detects that the reset signal is low. Assuming a reset takes about 1ms. The CPU is turning on , initializes the registers using a bootloader and then clears the registers because of what you described and then resets. The state diagram would be like poweron-reset- poweron and this continues indefinitely. Having the CPU reset frequently can be seen as a bug or flaw. \$\endgroup\$
    – Amit M
    Commented May 31 at 10:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.