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?
Answer
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.
How can I handle capacitive sensors with varying overlay thickness in cslib? Is it possible to set different touch deltas for different sensors?
Answer
It is not possible to set touch deltas on a per-sensor basis in the current version of cslib. However, you can alter the drive strength for each channel to compensate for different overlay thickness.
When using the auto reset feature of the C8051F930's SmaRTClock, what should I set the match value to?
Answer
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?
Answer
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?
Answer
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.
Why do I see higher current consumption than your data sheet claims when I operate the device from the 24.5 MHz precision oscillator?
Answer
There are two common reasons for this.
First, check to make sure that you are not driving the system clock (or any other clock) out on a GPIO pin. A 15 pF load that is switched at 24.5 MHz will consume more than 1 mA from a 3-volt supply.
Second, make sure that the Flash one-shot timer is disabled whenever the SYSCLK frequency is greater than 10 MHz; failing to do so can add between 1-2 mA to the chip current consumption.
How to use EFM8LB1 I2C slave, it looks quite different from SMBus peripheral.
Answer
The EFM8LB1 contains a I2C slave peripheral, it includes many interesting features which helps on high speed transfer but may cause confusion to the user who was familiar with legacy SMBus operation. Here we make a brief intro of I2C slave, and attach an I2C slave bootloader example code for reference.
The I2C peripheral contains 2 bytes FIFO and 1 byte shift register for TX/RX individually. The I2C slave support auto ACK/NACK an I2C master, it is controlled by BUSY bit field of I2C0CN0 register. In default, the BUSY is "1" which the device will not respond to an I2C master. All I2C data sent to the device will be NACKed. We should set this BUSY bit as "0", the device will acknowledge an I2C master. For a case, the master keep sending data to device, the device ACK the master automatically for max 3 ACKs since two bytes in FIFO and 1 byte in shift register. And then the SCL is hold low to indicate device is not capable to receive more data. We should check RXE bit field of I2C0FCN1 register to know if there is data in FIFO, read received data from I2C0DIN register.
The auto ACK feature makes difficulty on flow control, as we mentioned above, the SCL is hold low when the RX FIFO is full, so that device can handle the data. What about the master changes read/write direction? There is another feature can helps on this situation. The FACS bit field of I2C0ADM register. The defaults value is "1" which means FORCE_STRETCH. When this bit is set, clock stretching always occurs after an ACK of the address byte until firmware clears I2C0INT bit. With this clock stretching feature, we are able to hand the flow control during read/write direction changes.
There is an I2C slave bootloader example code which base on AN945, please take a look into it and have a reference on how the I2C slave works under polling mode.
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?
Answer
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.
8-bit Knowledge Base
Choosing C8051 Crystal Oscillator Drive Level (OSCXCN.XFCN Value)
Software Licensing and Use Permission for Silicon Labs C8051/EFM8 Header Files
C8051F9xx Oscillators and use cases
Variable overlay thickness for capacitive sensors
SmaRTClock auto reset on the C8051F930
High Frequency Oscillator Precision over Device Life
Wake EFM8UB1/EFM8BB2 Devices from Snooze Mode with SPI
C8051F9xx Current Consumption with 24.5 MHz Precision Oscillator
How to use EFM8LB1 I2C slave
Using the USB Debug Adapter to debug EFM8 on custom boards and EFM8 STKs