The EFM8BB3 and EFM8LB1 devices contain features to enable the retention of static DAC output and DAC configuration non-power on resets (POR). The DAC retention features are configured by setting the RSTMD bits in the DACnCF0 registers, which will cause the DAC output voltage and precision reference to persist through all resets except for power-on resets. Setting the DACnCF0.RSTMD bit causes the retention of the DAC SFR values and the output voltage on the DAC pin corresponding to the DACnH : DACnL data registers. Any waveform generation that was the result of firmware or other hardware modules on the device working to update the DAC would require firmware to reconfigure any hardware modules or firmware algorithms responsible for the waveform generation (i.e. updating the DACnH : DACnL data registers) after the non-POR reset.
The EFM8BB3 and EFM8LB1 devices contain a feature to enable the retention of port I/O output state through non-power on resets (POR). Setting the PINRSTMD bit in the PCON1 register will cause the port I/O state to persist through all resets except for power-on resets. The following sequence correctly describes the operation of the PINRSTMD feature:
1) Normal operation – MCU running
2) Firmware sets PINRSTMD bit. Writes to PxMDIN, PxMDOUT, Pn, and XBARE registers still affect pin mode and output state.
3) Non POR-reset occurs. At this point, the PxMDIN, PxMDOUT, Pn, and XBARE registers are reset, but output state of the port pins remains unchanged. PINRSTMD bit remains set.
4) While PINRSTMD is still set, firmware can write to PxMDIN, PxMDOUT, Pn, and XBARE registers, but no changes will occur to the pin modes or output states.
5) Firmware clears the PINRSTMD bit. Pin mode and output state are updated to reflect any changes in PxMDIN, PxMDOUT, Pn, and XBARE registers since the non-POR reset.
6) Firmware sets PINRSTMD bit. Writes to PxMDIN, PxMDOUT, Pn, and XBARE registers still affect pin mode and output state. (same as step 2)
What is the maximum storage time or shelf life of C8051Fxxx and other IC devices in their original packaging?
While an absolute maximum shelf life for C8051Fxxx, EFM8, and other IC devices may not be explicitly specified, there are requirements for shelf life and device handling that are based on JEDEC standards and device moisture sensitivity level (MSL). The MSL and E-Time are listed on the package anti-moisture/anti-static bag, as shown in the following knowledge base article:
Generally speaking, Silicon Labs packaging and handling procedures conform to JEDEC standard J-STD-033C, which defines Handling, Packing, Shipping and Use of Moisture/Reflow Sensitive Surface Mount Devices standards. According to this document, devices properly packed and sealed have a shelf life of 12 months from the date of seal, and if the storage time is between 12 months and 2 years, the devices can still be mounted on a PCB and soldered if the humidity indicator card (HIC) contained withing the sealed package indicates that baking is not necessary. If either the shelf storage time exceeds 2 years or the HIC indicates a humidity level that requires re-baking, then the devices must be re-baked to remove excess moisture prior to mounting and soldering. The required baking times and procedures are described in the JEDEC standard J-STD-033C (https://www.jedec.org/document_search?search_api_views_fulltext=j-std-033c).
After devices in a sealed package have been opened (i.e. the anti-moisture bag has been opened), they are subject to a floor life, which is dependent on the moisture sensitivity level (MSL) of the device. For instance, in the case of the C8051F340-GQ, the MSL is 3, which corresponds to a floor life of 168 hours in an environment of <=30 deg C and 60% relative humidity. Note that this time is subject to change under different ambient temperature and humidity conditions. After the floor time has been exceeded, device baking is required to ensure safe moisture levels. The MSL for Silicon Labs devices can be found on the packaging (i.e. anti-moisture/anti-static bag label) or through the Environmental and Quality Database, as described in the following knowledge base article:
Debugging the cause of an unexpected reset can be tricky, as the debug link can be affected and some systems will not have an easy way to get the reset cause information out of the MCU for analysis. The following idea may be useful to easily visualize the RSTSRC status whenever you come out of reset, as long as you have 7 GPIO pins to indicate the status of the RSTSRC register bits. If you do not, then you can use as many as you have and select and/or change the bits you feel most important to view. I have set up the following code to use GPIO port P2, but you can modify this to use whatever pins you have available. In this scenario, you would run the following code along with your initialization early in your main() function (i.e. before the main loop) to check the reset source and visualize this by monitoring the pin that corresponds to each reset source in the RSTSRC register:
/* Ensure that the crossbar is enabled
* Set up 7 GPIO to indicate status of RSTSRC bits
P2MDOUT |= 0x7F; // set P2.0 - P2.6 to push-pull
P2 &= ~0x7F; // clear P2.0 - P2.6
/* check RSTSRC status and indicate with GPIO pins */
rst_src=RSTSRC & 0x7F; // get RSTSRC value
P2 = rst_src; // set P2 indicator pins
I am using a C8051F930-GDI in die package and are connecting the die to the pcb by using wire bonding and glue. Is is useful to use conductive glue in order to connect the body of the die to the ground?
The back of the die on Silicon Labs C8051F930-GDI devices is simply a silicon substrate and does not need to be attached to ground. The MCU connections to ground will be via the bond wires from the die to the PCB. Our suggestion is not to use an electrically conductive adhesive but to use a thermally conductive adhesive for heat dissipation. The manufacturing process is also easier using a non-conductive adhesive. In general, your contract manufacture should know the best practice for bare die mounting and you should double check with them.
After choosing 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.
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:
I am using the USBXpress/Direct Access firmware library on my 8-bit MCU, and data transfers to/from the device works fine with Windows hosts. When using an Android host, the bulk transfer from the host to the device appears to work, but I am unable to read data from the device USB OUT FIFO (i.e. embedded calls to "Block_Read(*buffer,number of bytes)" fail).
This can be caused by differences in the host OS USB control transfers that occur when the USB device is opened by the host. On the Windows system, following a library command "SI_Open()," the host sends two setup commands:
0x40 0x00 0xFF 0xFF 0x00 0x00 0x00 0x00
0x40 0x02 0x02 0x00 0x00 0x00 0x00 0x00
followed by an In command Data1 length = 0.
In some cases, theses setup commands and the In command Data1 length = 0 are not sent by the Android host (when using the Android USB library and the "openDevice()" method).
Try adding control transfer commands with the data mentioned above before the bulk transfer commands. For instance: