Afterchoosing an external crystal for a C8051 MCU, there are several guidelines in the device datasheets for ensuring that you configure the MCU oscillator drive circuit correctly to match the specifications of your crystal. Specifically, it is best to configure the MCU to deliver drive current appropriate for the recommended drive level (generally expressed in µW) of the crystal without exceeding the maximum drive level. Overdriving a crystal resonator can have a number of negative effects, including reduced device operational lifetime, cracking of the crystal structure, and device failure. The image below shows an example of some crystal resonator specifications from a sample datasheet .
For this example, let's assume that we are working with a 24 MHz crystal. Additionally, we are using tables and information from the C8051F550 datasheet for this example.
The C8051 datasheets provide several methods for determining the correct External Oscillator Frequency Control Bits (XFCN) in the Oscillator Control Register (OSCXCN[2:0]). The datasheet register description contains the following table for determining the correct XFCN setting based on frequency:
Based on this table, for a 24 MHz crystal we would choose XFCN = 111b. Some C8051 datasheets, including the C8051F550 datasheet, have been updated to include a Crystal Drive Current specification in the Electrical Characteristics section:
The drive level (DL) of a crystal is given by the equation
DL = ESR * (I^2)
where DL is expressed in Watts, ESR is the crystal equivalent series resistance in Ohms, and I is the drive current, given in Amps. Using the drive currents for each XFCN value in Table 5.8 and the crystal device specifications, we can calculate the DL for this crystal at each XFCN setting:
Given that the target DL for the crystal is 10 µW and the max DL is 100 µW, this calculation tells us that the most appropriate XFCN setting for this application is in fact XFCN = 110b.
Using the Crystal Drive Current from the C8051 device Electrical Characteristics section, if available, to calculate drive level is the recommended method for determining the XFCN setting for a given crystal. While not all of the C8051 family device datasheets have been amended to include this specification table, the drive currents for all C8051 devices will be similar because the drive circuits are similar or the same. Variations in actual current levels will occur due to some factors, including different manufacturing process technologies. It is recommended that you consult the device datasheet for your particular device for the most accurate drive current specifications.
Older versions of the Silicon Labs 8-bit software development kit (SDK) contained device specific header files (i.e. "C8051Fxxx.h") as well common header files that were referenced and included by the device-specific files (i.e. "compiler_defs.h"). While most current Silicon Labs example code and source files in the C8051/EFM8 SDK are covered solely under the Silicon Labs End User Software License Agreement (http://developer.silabs.com/legal/version/v11/Silicon_Labs_Software_License_Agreement.txt), "compiler_defs.h" contains sections of code which were authored by a third party and are covered by a separate license agreement.
For those wishing to develop their application code using Silicon Labs-provided example code and header files, but wishing to have this code be covered under a single license agreement from Silicon Labs (see link above), we have created a new file called "si_toolchain.h" that supersedes "compiler_defs.h." In the 8051 SDK, the correct device-specific files to use for C8051 devices are called "SI_C8051Fxxx_SI_defs.h." Files with this naming convention will reference and include "si_toolchain.h" and will fall exclusively under the Silicon Labs End User Software License Agreement. These updated files should be available in the Silicon Labs 8051 SDK after April 19, 2017.
Why are there so many different integrated oscillators on this product? When would you typically use each of them?
The C8051F9xx devices have four different oscillators that may be used to derive the system clock. The precision internal oscillator allows for increased integration and external component elimination. This 24.5 MHz oscillator eliminates the need for an external crystal oscillator or resonator. With a spec of ±2 % across all voltage and temperature conditions, it is accurate enough to generate the communication clock for the standard UART baud rates. It consumes approximately 300 μA of current. A spread spectrum mode is provided to minimize electromagnetic interference (EMI).
For applications that do not require ±2 % accuracy, the low-power internal oscillator may be used. It is a 20 MHz oscillator with ±10 % accuracy across all voltage and temperature conditions, and it consumes less than 100 μA. The C8051F9xx external oscillator provides four modes of operation—external crystal, capacitor, RC network, or external CMOS clock source—that allow the user to set a clock frequency between 20 kHz and 25 MHz.
Finally, the smaRTClock peripheral includes a very low power 32.768 KHz crystal oscillator that can be used both as the clocking source for the real time clock and as the system clock. The smaRTClock oscillator has a self-oscillate mode (with provision for internal digital calibration of the oscillation frequency) for low-cost timekeeping applications that do not require the accuracy of a crystal.
When using the auto reset feature of the C8051F930's SmaRTClock, what should I set the match value to?
The alarm match value should be set to 2 less than the desired match value. Version 1.4 of the datasheet incorrectly states that it should be 1 less than the desired match value. This will be corrected in the next version of the datasheet.
C8051 and EFM8 devices include a high-precision 24.5 MHz internal oscillator, with a minimum / maximum frequency specification of 24 MHz / 25 MHz (2% accuracy). Is this specification guaranteed over the life of the device?
Yes. This specification is guaranteed to be held across the entire life of the device.
These devices have been characterized with a 1000-hour high-temperature operational life (HTOL) to determine how the devices will change over their lifetime. For the precision internal oscillator, no significant change was observed.
In Table 1.1 of the BB2/UB1 datasheets, the device lists the capability to be awakened from snooze mode by SPI0 activity. The SPI is also described with the feature that it "Can operate in suspend or snooze modes and wake the CPU on reception of a byte." What is required for this to work?
Firstly, the device must be in slave mode. Secondly, the Read Request Interrupt Enable bit (RFRQE) in the SPI0 FIFO Control 0 register (SPI0FCN0) must be set. It is not necessary to use the SPI with interrupts in order for this to work.
Can I use the USB Debug Adapter (UDA) to debug an EFM8 device on my custom PCB as well as to debug the EFM8 device present on the EFM8 Starter Kit (STK) (instead of the on-board J-Link adapter) in Simplicity Studio v4?
Yes, the Silicon Labs 8-bit USB Debug Adapter (UDA, Figure 1) can be used to debug an EFM8 device in Simplicity Studio v4, regardless of whether it is on a custom board or on a Silicon Labs EFM8 starter kit (i.e. the EFM8 present on the starter kit for evaluation purposes). Besides the requirement that the device be powered with correct hardware configuration (i.e. bypass capacitors, etc.), the only connections necessary for debugging in this case are C2D, C2CK, and GND.
The following image shows the correct connections to make to debug the EFM8 MCU present on the STK. Note that if the MCU is powered from the on-board debug USB (J-Link) connector, then the board controller may attempt to drive the target MCU C2 debug signals, creating contention with the USB Debug Adapter C2 signals. For this reason, it is safest to configure the STK debug to “OFF” mode (or to power the device from the coin cell battery or an external power supply, with the J-link USB connection disconnected).
The following image shows the correct/corresponding pins needed for use on the UDA:
C2D – pin 4
C2CK – pin 7
GND – pins 9, 2, or 3 (only one of these is necessary)
Finally, this is what it will look like when SS v4 is connected to the device using the UDA:
The process to connect to, program, and debug an EFM8 device on a custom board is analogous to the above discussion. You must simply ensure that the device is powered correctly as recommended for your device and provide a three pin header/connector (connected to C2D, C2CK, and GND) on your custom board similar to that shown on the EFM8 STK, which will serve as an attachment point for the UDA.
Does Silicon Labs sell a socketboard for programming the EFM8SB1 in the CSP16 package "out of circuit" (i.e. before soldering down to a custom board)?
Silicon Labs does not have a socket board available for purchase for programming the EFM8SB10F8G-CSP16. However, we did design a socket board for internal use with this chip/package. The schematic, bill of materials, and gerber files for this board are attached to this article. These can be downloaded and used to make your own board for programming purposes.
SOCKET FOOTPRINT CHANGE.png
An alternative to programming parts using a socketboard in situations where in-circuit production programming is not an option is to order pre-programmed parts directly from Silicon Labs. This is especially the case with a package such as the CSP16, as these are very small packages that are a bit difficult to deal with, and programming them with a socketboard would be very cumbersome in any quantity. To order pre-programmed parts, please contact Silicon Labs Sales: