ATmega32u4 reset circuit and bootloader

Question

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:

And my reset circuit looks like this:

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):

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

I plan to go with the 4^th 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.

Notes:

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.

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.