I have an ATmega32u4 which I have configured to run its application by default at boot, and to run the bootloader (standard DFU USB bootloader from Microchip) when the reset button is pressed. I intend to use the bootloader for flashing the application using Atmel Flip.

I have the fuse bits set as follows:

fuse bits

And my reset circuit looks like this:

reset circuit

But, I found that this did not work - and the bootloader is always run at power-on instead of the application. This is a little baffling, but it gets worse...

I found that if I remove the 10 k pull-up (R441), it works as expected (the app runs at boot, and bootloader runs on manual reset).

Furthermore, I found that if I leave the 10 k installed but replace the 1 µF cap with 0.1 µF it also works.

And if I remove the cap altogether it works as well.

  • Fails
    • R441 - 10 k
    • C166 - 1 µF
  • Works
    • R441 - DNI
    • C166 - 1 µF
  • Works
    • R441 - 10 k
    • C166 - DNI
  • Works
    • R441 - 10 k
    • C166 - 0.1 µF

At first I thought the time constant with the 1 µF cap was too large, and the µController was reading the pin as a reset (active low) at boot, but that doesn't explain why it works when R441 is not populated. The ATmega32u4 has an internal weak pull-up, and using it alone would cause a much larger charge time.

I can't find the value of the weak internal pull-up in the documentation, but I estimate it to be somewhere around 50 k, based on some oscope measurements:

Probe at TP87
With R441 un-populated (and 1 µF cap):

charge time with R441 DNI

With R441 (10 k) installed (and 1 µF cap):

charge time with R441 installed

I plan to go with the 4th configuration in my bullet points above (10 k and 0.1 µF), but I would love to understand why it is behaving this way. I would hate to find that it is working now, but fails to work later when fielded due to a new thermal environment or something.


  1. The HWB pin is pulled to ground through a 10 k
  2. The HWBE and BOOTRST fuses are configured such that the application code should execute at boot unless external conditions apply: namely that reset is pulled low, sampled on the reset’s rising edge.
  3. The application itself has no calls to jump to the bootloader.

HWB description

enter image description here

enter image description here

  • \$\begingroup\$ PS. I have changed the value of R443 from 33.2 Ohms to 330 to be more in line with AN2519, but that doesn't affect the results, and doesn't really pertain to the question. Thanks \$\endgroup\$ Aug 26, 2021 at 0:20
  • 1
    \$\begingroup\$ Please put your PSs in the question, you can edit your question. \$\endgroup\$
    – Tyler
    Aug 26, 2021 at 0:56
  • 1
    \$\begingroup\$ @Tyler well, as I said in the comment, it doesn’t really apply to the question, and all of my testing was done with the circuit as shown in the question. If it’s distracting, I can just delete the comment. \$\endgroup\$ Aug 26, 2021 at 0:58
  • \$\begingroup\$ @BlairFonville you forgot to mention how do you determine between the two scenarios, reset rising up due to power being applied, or reset rising up due to someone pushing the button? How would the MCU know which case it is and what code to run based on it? \$\endgroup\$
    – Justme
    Aug 26, 2021 at 4:56
  • \$\begingroup\$ @Justme Thanks for the comment. It’s a function of the mcu to run the application code by default, unless external reset conditions apply, given the fuses as I have configured them (namely HWBE and BOOTRST). This is dependent on the HWB pin which I did forget to mention. I’ll had clarify remarks. \$\endgroup\$ Aug 26, 2021 at 5:08

1 Answer 1


I haven't used this particular MCU, but generally: never mess around with cap values on the /reset pin of any MCU. Pick what the manufacturer tells you.

In this case I can't find the recommendation in their datasheet, but 1uF sounds like a lot. This cap needs to suit the reset flanks and downtime of the part or you'll get very strange problems, if the cap starts affecting rise and fall times. Some parts need steep reset flanks.

It would appear that the intention here is to put a RC filter on the tact switch to de-bounce it. Makes sense, since a bouncing physical switch directly on the reset pin isn't a brilliant idea: you'll get spurious resets as well as ESD and EMI vulnerabilities.

If you can't get this working, then place something like a Schmitt trigger buffer IC in between the RC filter and the reset pin, so that the cap in the RC filter doesn't affect /reset. Move the pull-up so that it sits close to the pin. Many parts don't even need external pull-up nowadays.

Also in general terms: don't wave around /reset traces all over your PCB. On most boards, it's the single-most critical signal in terms of EMC. Why people keep insisting on putting physical switches directly on it, I have no idea. It's bad enough to expose it to some JTAG connector.

"It's good for debugging". Just find the reset button in your in-circuit debugger software and click on it with the mouse... or toggle the supply on/off.

  • \$\begingroup\$ Thanks Lyndon. These are good notes. I agree with your comments regarding the signal transition, but the results seem to contradict the logic. Specifically, the fact that it works with 1 uF cap when the pull-up is not installed is bewildering. I.E. it works with the top oscope image, but not the bottom one. \$\endgroup\$ Aug 26, 2021 at 22:46
  • \$\begingroup\$ Oh, and yes, my tact switch is located right next to the mcu and the trace is short. The reset switch is necessary. It won’t work as a soft reset. It’s not for debugging; it’s for jumping to the bootloader for flashing the chip. Power-cycle can’t substitute as a reset since the application runs at power-up, and the bootloader runs at reset. Thanks. \$\endgroup\$ Aug 26, 2021 at 22:52
  • \$\begingroup\$ @BlairFonville Why would the bootloader need a power-on reset? That sounds unlikely. As I wrote, you could just use any GPIO for the switch then generate a watchdog reset. \$\endgroup\$
    – Lundin
    Aug 27, 2021 at 6:25
  • \$\begingroup\$ I’m may not have been clear, or I’m confused by “power-on reset”. We will fab the boards, kit, and assemble. The bootloader is preinstalled on the chips (they’re sold that way). But there is no application code (yet) to read gpios. The PWAs will be installed in the equipment we’re building. The reset switch and the ucontroller’s USB will be installed on the front panel. Pressing the reset tells the mcu to jump to the bootloader, which instantiates the USB. The USB is then used with Flip (software) for flashing the device. \$\endgroup\$ Aug 27, 2021 at 6:40
  • \$\begingroup\$ @BlairFonville Sounds like it would have been much cheaper to just buy the parts pre-programmed then. \$\endgroup\$
    – Lundin
    Aug 27, 2021 at 6:43

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.