Custom PCB Design with an EFM8 Microcontroller

January 18, 2016 by Robert Keim

Tips and techniques for incorporating EFM8 microcontrollers into your custom hardware.

Tips and techniques for incorporating EFM8 microcontrollers into your custom hardware.

Supporting Information

Beyond the Dev Board

The wide availability of reasonably-priced development boards is extremely advantageous for students, hobbyists, or anyone else who needs to evaluate a device’s functionality without the cost, complication, and risk of designing, fabricating, and assembling a prototype PCB. Actually, the right dev board could even find a permanent place in a prototype or low-quantity project—the overall cost might be lower than with custom hardware, and you don’t have to worry about those pesky little schematic/layout mistakes that turn your shiny new PCBs into awkwardly shaped paper weights.

On the other hand, dev boards are seriously constraining, and it may not be long before you want a PCB that is perfectly suited to your specific requirements. If you can draw the schematic and lay out the board for free (with DesignSpark, KiCad, CircuitMaker, etc.), then use a budget-friendly PCB fab (OSH park is hard to beat, but also check PCB Shopper), then assemble the board manually or via toaster-oven reflow, you just might find yourself with a high-performance, fully functional, custom-designed PCB at well under $100.

If you look through my previous articles you will find quite a few projects based on a development board for the EFM8UB10F16G, which is one of the devices in Silicon Labs’ new EFM8 series of small, low-cost, low-power, 8051-based microcontrollers. But some future projects will transcend the dev board and make use of custom hardware, so as a prelude to that, this article will provide some guidance on successful hardware design with an EFM8 device. This device-specificity notwithstanding, the general concepts presented here are applicable to numerous other microcontrollers that share features with the EFM8 series.

The Families

The EFM8 series consists of four product families: Universal Bee, Sleepy Bee, Busy Bee, and Laser Bee.



You can find details about each family on the Silicon Labs website. This article will focus on the Universal Bee, which I think is the most useful for general prototyping and tinkering because it incorporates USB connectivity—I find that most projects are greatly improved when I can easily establish communications between a PC and the microcontroller. The various EFM8 devices are similar in architecture and general hardware requirements, but before you start your design make sure you check the datasheet and reference manual (particularly the data sheet, e.g., this document) for your particular part number.

It Doesn’t Take Much . . .

The first thing to understand about the EFM8 devices is that they exemplify the outstanding level of integration found in many of the latest microcontroller families. The list of necessary external components is surprisingly short, though prototypes and such will generally need more than the minimum required for production designs. The parts needed to get your EFM8 up and running can be grouped into four categories: power, programming/debug, communication, and voltage reference. Let’s take a look at each one.


In the old days there were various ways to power a microcontroller project: wall transformer, homemade rectifier, 9 V battery, AA batteries. I suppose these options still exist, but nowadays I simply ignore them because they are so inferior to USB. Every USB port provides reasonably clean 5 V power with plenty of current for most applications, and it’s usually not difficult to find a USB port somewhere nearby—computers, tablets, USB chargers, wireless speakers, etc. And along with the 5V you get a robust, standardized, fairly straightforward communications interface. Furthermore, USB connectors—you have three sizes to choose from—and their corresponding cables are widely available (my guess is that you already have at least a few USB cables lying around).

Considering these advantages, it is no surprise that Universal Bee devices incorporate a voltage regulator designed to generate 3.3 V from 5 V USB power (the other EFM8 families do not include this feature).



Even better, this regulator can supply 100 mA, which means you might be able to power your entire board with the EFM8’s 3.3 V output.

So to power your Universal Bee from USB, connect the VBUS signal directly to the VREGIN pin and enable the internal regulator. The 3.3 V is routed to the EFM8’s internal circuitry and driven on the VDD pin. Next are the bypass capacitors for VDD and VBUS. I like to follow datasheet recommendations whenever possible, so we need 1 µF and 0.1 µF caps for the VREGIN and VDD pins:



Notice here that I have used some extra filtering on the VBUS line. The 10 µF cap provides a larger charge reservoir for smoothing out lower-frequency variations in the supply voltage, and the ferrite bead helps to suppress high-frequency noise (the Clean Power series contains an abundance of information on power supply filtering and bypassing). The last thing you need is ESD (electrostatic discharge) protection, discussed below under “Communication.”


After you install your EFM8 and apply power, it will do . . . pretty much nothing. You need a way to load a program into the flash memory. The EFM8 series uses Silicon Labs’ proprietary two-wire programming and debugging connection, known as the “C2 interface,” in conjunction with a USB debug adapter:



The easiest way to connect your microcontroller to the debug adapter is through a 10-pin, 2-row, 0.1-inch header (such as this one). Two of the header terminals must be connected to the EFM8’s C2D and C2CK pins. Three of the header terminals can be tied to ground, but one ground connection is sufficient. The pinout is as follows:



You also need to make sure that pin 1 on the ribbon-cable connector matches up with pin 1 on the header. I do this by incorporating idiot-proof instructional material into the PCB footprint:




As mentioned above, I highly recommend that you incorporate PC-to-microcontroller communications into your projects. Once upon a time we used RS-232, but nowadays USB makes much more sense. Universal Bee devices (among others) make this very simple; everything except the ESD protection diodes is integrated into the chip.



Here I am using a three-in-one ESD protection solution, but discrete diodes (such as this one) are fine too. The VBUS pin is used to determine whether the USB peripheral is connected to a host, so tie it to the USB VBUS signal. (Actually, the datasheet for EFM8UB1 devices indicates that it is not always necessary to connect the VBUS pin, but I would do it anyways.)

Whenever you’re dealing with high-speed differential signals, it is good practice to match trace lengths and minimize parasitic inductance and capacitance. Don’t stress too much, though, because the EFM8 devices are limited to USB “full speed” (i.e., 12 Mbit/s), so the layout is not nearly as critical as with USB “high speed” (480 Mbit/s). I simply arrange the EFM8 so the USB pins are adjacent to the USB connector.



You will notice that the D+ and D- pins on the EFM8 are reversed relative to the pinout of a USB Mini-B or Micro-B connector; this is somewhat annoying, but easily remedied by dropping a pair of vias and running one signal on the bottom layer so that the other can cross over. For example:


Voltage Reference

This is not strictly necessary, but many applications benefit from some sort of analog-to-digital conversion. EFM8 microcontrollers have everything you need—ADC, multiplexer, temperature sensor, voltage reference . . . except a bypass capacitor for the voltage reference circuitry. So even if you don’t expect to need analog functionality, this one capacitor is insurance in case you change your mind.




As this article demonstrates, incorporating EFM8 devices (and other user-friendly, highly integrated microcontrollers) into custom hardware is not complicated. In future articles we will use the PCB shown in the above photos for interesting projects that would be seriously painful to implement using a dev-board-plus-breadboard approach.