USB ESD protection problem and improved USB detect circuit for battery powered devices

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.


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:

Repair of my Onyx Boox M92 e-ink display

I apologise, but I just have to brag a bit (a lot actually).

My old faithful Onyx Boox M92 9.7″ e-ink reader stopped working a month ago. I was quite upset, because I used it frequently to read data sheets and engineering books at night. It would start up and display faint grey pixels that gradually got darker over a period of a minute. When I navigated the application icons a ghostly rectangle would move where the application icons are supposed to be. This led me to believe that the processor was OK, but the display was not.

I examined the flat flexible cable of the e-ink display using a high-end Olympus SZ51 microscope and could not find any hair-width cracks in the tracks, until I lifted up the Kaptan tape and saw the tight Z-bend:


The person assembling the unit pressed down so hard on the Z-bend on the right-hand side that the ribbon cracked at the fold. It worked for years (the tracks just touching) until one day it yielded. I could barely see the faint crack lines of the tracks on the outside of the fold at 40 x magnification, but unfolding it finally revealed the problem.

I carefully scraped away the insulation, tinned the tracks and attached wires (0.2mm in diameter) using my Metcal MX-5000 rework station. The tracks were as thin and brittle as gold leaf and would be prone to flaking away during the scraping. This was the final result:


When the unit magically worked again… wow what a feeling!! In total that was 4 hours well spent 🙂


  1. Don’t skimp… buy quality tools (within limits)
  2. Patience (a steady hand)
  3. Perseverance (in truth pigheadedness)
  4. If I did not blow my budget on quality tools, I could afford a new 13.3″ Onyx Boox MAX… ha ha!

Happy holidays!

UPDATE! 2018-09-14

Well my repairs lasted nearly two years, but the honeymoon’s over. It stopped working again and I tried to repair more broken tracks. I used double-sided tape to keep the FPC cable down… bad mistake! Second time I tried separating the cable from the tape, it tore the tracks right off the cable 🙁

I think the apt term is BER (Beyond Economic Repair).


Piconomic FW Library 0.5.0 released

The people have NOT spoken and I have listened…

After careful thought and long internal deliberation I have decided to remove the obnoxious advertising clause from the Piconomic FW Library Open License, because it could impede the adoption and future growth of the library. Henceforth the standard 2-clause simplified BSD license will be used to grant freedom for open source and commercial (closed source) projects.

I hope that eliminates all obstacles now.

The Gerber files for the Piconomic Scorpion Board has also been released and can be downloaded here.

Piconomic FW Library 0.4.4 released

Major changes:

  • All AVR projects and documentation has been updated from Atmel Studio 6.2 to 7
  • Simplified Atmel Studio and UnixShellUtils build process by using custom build tools option… see here
  • Upgraded all AVR Makefiles and to automatically prefix -D to CFLAGS, CPPFLAGS and AFLAGS
  • Upgraded to Doxygen 1.8.11
  • Updated CLI module
  • Added digital input debounce module


Debouncing a digital input such as a button

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

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.


Logging harvested solar power using $15 Scorpion Board

It’s undeniable that South Africa is experiencing a critical electricity crisis. On the positive side, it’s forcing us to conserve and consider alternative sources of energy. My mom sponsored our household with a cheap Chinese solar panel with battery pack and LED lights to use during load shedding (we live in Cape Town zone 6 and you can find the schedule here).

This made me wonder: how much solar power does this system harvest in one day? Enter my handy $15 Scorpion Board. I built a cheap current sensor board (using a Diodes ZXCT1051 low side current sensor IC). Schematic:


Then I populated the Scorpion Board with the optional Lithium battery connector and charger, connected the current sensor board and calibrated it using a bench supply and electronic load. This part is easy. Using the command line ADC Data Logger App I set the ADC scale to 1.0 and the offset to 0.0 of each channel and set the board to sample each channel continuously:

>log fit 0 1.0 0.0

>log fit 1 1.0 0.0

>log fit 2 1.0 0.0

>log fit 3 1.0 0.0

>log s

The output values correspond to the raw ADC values and I noted the ADC value for different voltages and load currents. This data was captured in a spreadsheet and a linear fit performed:


The voltage measurement is super accurate (<0.3%) and the current measurement accurate enough (<2.5%). Now I have the calibration values and can set them as follows (ADC#0 is used for current and ADC#2 is used for voltage; I’m not interested in ADC#1 and ADC#3 so the scale and offset is set to zero):

>log fit 0 1.100399391 -5.277095671

> log fit 1 0 0

> log fit 2 35.4527418 50.83118688

> log fit 3 0 0

Nothing left but to set the date & time, the logging interval to 60 seconds, and start logging:

>rtc w 15-05-27 06:30:00

>log samples 60000

>log s

Here is a picture of the solar charger system with the power logger, before I placed it on my roof:


At the end of the day, I stopped logging by pressing the user button and dumped the data:

>log ls

File 1 [15-05-27 06:30:37]

>log dump 1

I imported the data into a spreadsheet and here’s the resulting graph:


The solar panel specs are:

  • Peak Power: 2W
  • Maximum Power Current: 0.23A
  • Maximum Power Voltage: 9V
  • Short Circuit Current: 0.267A
  • Open Circuit Voltage: 11.25V

The system harvested 528mAh (at about 7.4V), or more accurately 4.1Wh (V x I x t) with mist in the morning and some clouds during the day. The peak power harvested was 1.73W. It can be observed that the system was not harvesting from the solar panel at it’s Maximum Power Point (MPPT).

It is the start of winter and rain is forecast for the whole week, so I will have to wait some time to repeat the run on a perfectly sunny day. Lesson learned: as an engineer, be realistic / pessimistic about the power that you can actually harvest versus the maximum / idealistic figures advertised for the product. To measure is to know…

The Scorpion Board was perfect for the job. It’s low price, small size, low power consumption and big ecosystem of software makes it the go-to board for jobs like these.

The 1987 April Fool’s joke that ignited my embedded career

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

SHARP PC-1500 Pocket Computer; Source

SHARP PC-1500 Pocket Computer; Image from

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.

ZX Spectrum 16k

“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

ZX Computing Apr 1987 cover – Image from

ZX Computing Apr 1987 page 57 - Image from

ZX Computing Apr 1987 page 58 – Image from

ZX Computing Apr 1987 page 58 - Image from

ZX Computing Apr 1987 page 58 – Image from

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:

April Fool screenshot

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!

Thanks for the first person who answered my poll… please contact me to collect your prize!

On 2015-03-28 03h19 (GMT + 2 hours) some kind soul was generous enough to give 10 seconds back and answer my poll about the Scorpion Board. Please get in touch with me: I want to repay your kindness by sending you a free Scorpion Board. Although I do not know who you are, there are ways of making sure that you are the right person.

The poll is not a marketing trick. I really am flying blind and need your feedback to know if I’m on the right path and should keep at it, or if it has no value and I should drop it and move on to something else.

I have decided to give away a free Scorpion Board once a month to a random person that responds to my poll on the Scorpion Board product page or Piconomic FW Library product page. Remember to add your e-mail address in the poll so that I can contact you. I hate SPAM too! I will never share your e-mail address or use it for marketing.

If you are a lecturer at a university and want to evaluate the Scorpion Board as a teaching aid, please contact me and I will ship a free Scorpion Board (offer limited to one free board per university).

This is why I don’t like Micro USB connectors

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

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

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?