I encountered this problem on the Atmel SAMD21 Xplained Pro Evaluation Kit.

The data-logging device that I developed is mainly battery powered, but uses USB every once in a while to download the data and recharge the internal battery. A resistor divider (R307 and R308) is used to detect when USB +5V is connected. This generates a rising edge interrupt on PA14 and wakes up the ARM micro from STANDBY sleep mode. The ARM micro then starts the USB stack, which enables an internal 1.5kΩ pull-up resistor to +3V3 on USB D+ (pin PB05). For more info regarding the pull-up resistor read this page regarding USB speed identification. The pull-up resistor basically tells the USB Host “hey, I’m here” and the operating system proceeds to enumerate the USB device.

The problem rears it’s head when USB is disconnected. USB +5V disappears, but the 1.5kΩ pull-up resistor to +3V3 stays enabled. There is a unintentional current path through the USB ESD protection diode D300 and the PA14 node voltage drops down to 1.2V (logic high), not 0V (logic low) as expected. Consequently, the ARM micro keeps the USB stack and the pull-up resistor enabled and wastes 33μA the whole time. That’s a lot if you want to make the device last a year.

Here is my improved circuit:

Yes, I know, it’s not earth shattering… I just tweaked the resistor divider values and added an extra resistor (R30). Here are some sound engineering calculations that proves that it will work over all tolerances (and that’s the difference):

When USB +5V is present (actually, it could be as low as 4.35V), the minimum voltage on PA14 will be 1.956V, which is still above the maximum threshold of 1.906V.

When USB +5V is absent, the USB Speed pull-up resistor will pull PA14 up to 0.966V (worst case), which is still below the minimum threshold of 1.040V (when VDDIO is 3.465V).

It is possible to unintentionally power up the device via low value resistor R1 when USB is connected, but R30 limits the amount of parasitic current that flows into GPIO pin PA14. Remember that there are internal ESD protection diodes connected to each GPIO pin of the ARM micro and this will form an unintentional current path to the VDDIO supply rail.

UPDATE!

I recently came across an alternative solution to the problem. There are ESD protection devices, for example WE-TVS 82400102 (Digi-Key part number 732-4473-1-ND) that have a diode to block the parasitic current flow:

When a button is pressed, the digital input to a microcontroller may “bounce” between high and low until it finally settles to a valid state (see this Wikipedia entry)

Button bounce captured on oscilloscope

Here is a complete, standalone Atmel Studio example project called debounce_example that demonstrates the usage of the included debounce module (debounce.h, debounce.c and debounce_cfg.h). The debounce module is is able to “debounce” a digital input by looking at successive values and deciding if it is a valid low or high state. It is also able to register and remember a rising edge event (e.g. key pressed) and falling edge event (e.g. key released).

It uses a simple binary state machine, counter and edge event flags to keep track of the debounced state of each digital input. It works by incrementing a counter each time the current digital input state is HI. If the counter reaches the high watermark threshold, the debounced state is considered HI. Conversely, the counter is decremented each time the current digital input state is LO. If the counter reaches the low watermark threshold, the debounced state is considered LO. The minimum counter value is 0 and the maximum value is DEBOUNCE_CFG_COUNT_MAX. This scheme provides sufficient hysteresis to debounce a noisy digital input.

If no hysteresis is required, then DEBOUNCE_CFG_THRESHOLD_LO can be set to 0 and DEBOUNCE_CFG_THRESHOLD_HI can be set to DEBOUNCE_CFG_COUNT_MAX.

The debounce module has been added to the piconomic-fwlib and the documentation is here.

Enjoy!

Here’s the anecdote that sheds some light on my roots…

SHARP PC-1500 Pocket Computer; Image from http://www.pc1500.com

My dad bought a secondhand Sinclair ZX Spectrum 16K for me after I blindly typed in a BASIC program that locked up his Sharp PC-1500 Pocket Computer (containing crucial university notes). It was 1983 and I was 9 years old. I think this was one of the best career investments… thanks Dad! It was spartan, but as Hermann Hauser recalled how ARM successfully designed their first microprocessor:

“…when we decided to do a microprocessor on our own, I made two great decisions: I gave Steve Furber and Sophie Wilson two things which National, Intel and Motorola had never given their design teams. The first was no money; the second was no people. The only way they could do it was to keep it really simple.”

Less meant more: it sparked my imagination  and forced me to dig deeper.

“ZXSpectrum48k” by Bill Bertram – Own work. Licensed under CC BY-SA 2.5 via Wikimedia Commons

Fast forward a few years  to when I browsed through the April 1987 edition of ZX Computing and found an article to upgrade a 16K/48K Spectrum to 128K using a simple BASIC program:

ZX Computing Apr 1987 cover – Image from http://www.worldofspectrum.org

ZX Computing Apr 1987 page 58 – Image from http://www.worldofspectrum.org

ZX Computing Apr 1987 page 58 – Image from http://www.worldofspectrum.org

Have a read! The web was spun so fine and strong that I truly believed that I could turn my puny ZX Spectrum 16K into the powerful 128K version. Problem was, the BASIC program was hard-coded to only work on a 48K (even though the article states that it will also work on a 16K). It poked machine code to address 32768 onwards and then executed the machine code. This was a clever way to obfuscate the true purpose of the program.

I could not get the program to work and I spent almost a year learning enough about machine code and assembly to decode the machine code, fix the absolute addresses so that it would execute at a lower address and turn it into machine code again. Note that I was 13 years old at the time, my English was limited (Afrikaans is my first language) and I had absolute no one that could help me.

When I finally succeeded, this was the screen that greeted me:

I looked a the cover of the magazine and noted that it was indeed the April 1987 edition. Alternative Program Register 1 indeed. I learned numerous lessons that day, but what stuck was a love of all things “bare metal“.

Thanks for indulging me… enjoy the rest of your day!

Lesson:  Don’t pack away your ATmel JTAGICE3 with the USB cable plugged in. When I wanted to use it again, I discovered that the connector was very “loose” indeed.

Atmel JTAGICE3 opened up

Here you can see that the GND pads tore right off the PCB. Note that brownish glue that was used on the two middle GND pads to keep the connector in place during SMD reflow. Thus all of the mechanical stress was placed on the two outside pads, because the two middle pads did not solder:

Broken Micro USB pads – zoomed in with Olympus SZ51 microscope

If I did not have access to a high-end Olympus SZ51 microscope and a Metcal MX-5000 Soldering, Desoldering and Rework Station, I don’t think I would have been able to repair it (but I did and I could). Sparkfun says that a lot of you prefer microUSB over miniUSB, but this is the reason why I chose to use min-B USB connector on the Scorpion Board.

What are your thoughts or preference?