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.
Can Comparator0 and Comparator1 have the same pins selected for use on the C8051F41x?
While the hardware configurator tool will not let you configure it this way, it is possible to have both comparators select the same pins. You will have to make this configuration outside of the configurator by modifying the initialization code directly.
Where can I find specs on the RST pin for EFM8 parts?
The EFM8 datasheets have a table called Reset and Supply Monitor that give reset specs such as RST Low Time to Generate Reset. For electrical specs, the RST pin has the same electrical specifications as the other GPIO on the EFM8 devices. You can refer to the Port I/O table in the electrical specifications chapter of the desired device's datasheet for more information such as Input Leakage.
Currently, in the EFM8 family, the EFM8BB3 EFM8BB2 EFM8LB1 and EFM8UB1 has I2C Slave module. And EFM8BB3 has the same I2C module as EFM8LB1, and EFM8BB2 has the same one as EFM8UB1. However, there is little difference between EFM8BB3 and EFM8BB2 (also EFM8LB1 and EFM8UB1) as below.
In EFM8BB3 and EFM8LB1, the Slave Address Mask (SLVM in the I2C0ADM register) can be used to define an address mask to enable automatic hardware response to multiple slave addresses. The I2C0SLAD field in the I2C0SLAD register, combined with the SLVM mask in I2C0ADM, defines the I2C0 Slave Address for automatic hardware acknowledgement.
However, in EFM8BB2 and EFM8UB1 there is no Slave Address Mask field. The I2C0 Slave Address for automatic hardware acknowledgement just be decided by I2C0SLAD in the I2C0SLAD register. When the received I2C address matches this field, hardware sets the I2C0INT bit in the I2C0STAT register.
For the EFM8BB3 and EFM8LB1, if the ADDRCHK bit is set in the I2C0CN0 register, the matching address will be placed in the receive FIFO, firmware can check the address after reading it from the receive FIFO using I2C0DIN register. But this function do not exist in in EFM8BB2 and EFM8UB1.
In EFM8BB3 and EFM8LB1, the FACS bit in I2C0ADM controls whether clock stretching is enforced (via setting of I2C0INT bit) after a matching slave address has been acknowledged. When this bit is set, clock stretching always occurs after an ACK of the address byte until firmware clears the I2C0INT bit. When this bit is cleared, the I2C0INT bit won't be set by the address ACK alone, but it may be set due to other conditions as detailed in the descriptions of the RD and WR bits.
However, in EFM8BB2 and EFM8UB1, there is no register for the Force Address Clock Stretching control, and the clock stretching always occurs after an ACK of the address byte until firmware clears the I2C0INT bit.
Slave Address Mask(SLVM)
Force Address Clock Stretching (FACS)
The STAL packet indicates that the endpoint has halted, or a control pipe does not support a certain request.
A function uses the STALL handshake packet to indicate that it is unable to transmit or receive data. Besides the default control pipe, all of a function's endpoints are in an undefined state after the device issues a STALL handshake packet. The host must never issue a STALL handshake packet.
Typically, the STALL handshake indicates a functional stall. A functional stall occurs when the halt feature of an endpoint is set. In this circumstance, host intervention is required via the default control pipe to clear the halt feature of the halted endpoint. Less often, the function returns a STALL handshake during a SETUP or DATA stage of a control transfer. This is called a protocol stall and is resolved when the host issues the next SETUP transaction.
As below is the captured USB bus data between an EFM8 HID device and Window PC USB host. The EFM8 HID device sends a STALL handshake in response to the get DEVICE_QUALIFIER descriptor request because the EFM8 HID device does not support the certain request. After that, the USB host will issue the next SETUP transaction.
Since the USB is a polled bus, meaning the host controller must initiate all transfers, so the behavior of USB transfers may depend on the USB host. As below is the captured bus data between the EFM8 HID device and MacOS PC, there is no any get DEVICE_QUALIFIER descriptor or other nonstandard request, so no STALL handshake can be found.
For the release of Silicon Labs' EFM8 product line, a factory bootloader was created. However, this bootloader only works natively on devices that are 'bootloader enabled'. These 'bootloader enabled' devices are:
The AN945 bootloader will also be compatible on any future EFM8 devices (including newer revisions of the above devices).
Bootloader enabled devices have the ability to check to see if they should jump to the bootloader or the application after a reset, before code starts running. Other Silicon Labs 8-bit devices, or older EFM8 devices, don't have this capability. However, you can change this by mimicking this function in the bootloader and application firmware.
Firstly, the bootloader image should contain a jump to the bootloader at the reset vector 0x0000. You can do this by adding the following code to the boot_startup.asm file in the bootloader project:
?BL_JUMP SEGMENT CODE AT 0 RSEG ?BL_JUMP LJMP boot_start
So, if there is no application, this will jump automatically to the bootloader.
Now, you need to modify your application code to mimic the bootloader capable parts' additional functionality. I've done this in the SILABS_STARTUP.A51 file of an application, since this is where you can insert code that effectively runs before your application. In here, we'll simply need to check to see if the bootloader exists. If it does, we'll jump there first and it will perform the other checks to see if we should go to the application.
However, in this case, we'll also need to determine whether we just came from the bootloader, since we technically are the application. Without this, we would get stuck in a loop - jumping from the application to the bootloader, back to the application, back to the bootloader, etc. I used R7 to store a particular value to say that we've just come from the bootloader. Here is the modified SILAB_STARTUP.A51 file:
CSEG AT 0 ?C_STARTUP: LJMP BootloaderCheck RSEG ?C_C51STARTUP #include "efm8_device.h" #define BL_SIGNATURE 0xA5 BootloaderCheck: ; Read and test R7 to see if we've already entered the bootloader ; since the last reset. If so, we should skip to the application mov A, #BL_SIGNATURE xrl A, R7 jz GotoApplication ; Read and test the boot vector enable byte (byte before Lock Byte) ; The signature is present if A is 0 (leave result in A) mov DPTR, #(BL_FLASH0_LIMIT - 2) movc A, @A+DPTR xrl A, #BL_SIGNATURE ; Restore the DPTR mov DPTR, #0000h ; If the signature is present, jump to the boot vector jz GotoBootVector GotoApplication: clr A ; Restore A mov R7, #0x00 ; Restore R7 jmp STARTUP1 ; Jump to reset vector (use this to save a byte) GotoBootVector: ; A = 0, no need to restore mov R7, #BL_SIGNATURE ; Write 0xA5 to R7 to indicate we've bootloaded ljmp BL_START_ADDRESS ; Jump to boot vector
The full SILABS_STARTUP.A51 file is zipped and attached to this forum post.
This appnote describes how to calculate the pull-up resistors for a particular I2C bus: http://www.ti.com/lit/an/slva689/slva689.pdf
The minimum resistance is pretty easy to determine, and is based on the bus voltage (Vbus), the maximum voltage that can be read as a logic-low (VOL), and the maximum current that the pins can sink when at or below VOL (IOL).
The formula is:
Rp(min) = (Vbus – VOL) / IOL
Formula 1. Minimum Pull-up Resistance
As an example, we will use an EFM8LB1 MCU, operating at VIO = 3.3V with an I2C speed of 400 kHz (fast mode), for the I2C bus characteristics. The EFM8LB1 datasheet is here: https://www.silabs.com/documents/public/data-sheets/efm8lb1-datasheet.pdf
For the LB1, VIL is 0.3 * VIO, which would be 0.99 V. This is the maximum voltage that will be registered by the LB1 as a logic low. In high-drive mode, the pins can also sink up to 13.5 mA while retaining a voltage of at most 0.6V, which is below the VIL threshold, so we can use that as the input for IOL.
This is the minimum pull-up resistance for an I2C bus composed of EFM8LB1 devices. Lower than this, and we cannot guarantee that the device can pull the I2C bus lines below VOL.
The maximum pull-up resistance is based on the needed rise-time of the clock (dependent on the I2C clock frequency), and the total capacitance on the bus.
The I2C specification (http://cache.nxp.com/documents/user_manual/UM10204.pdf) lists the maximum total bus capacitance with a pull-up resistor to be 200 pF (it can be up to 400 pF if the pull-up is a current source, section 5.1).
This specification also describes the rise-time of SDA/SCL to be a maximum of 300 ns in “Fast-mode” – 400 kHz (table 10).
Back to the appnote: the formula for calculating the maximum pull-up resistance is:
Rp(min) = rt / ( 0.8473 * Cb )
Formula 2. Maximum Pull-up Resistance
Where rt is the maximum allowed rise-time of the bus, and Cb is the total bus capacitance.
The appnote actually already calculated this for the worst-case Fast Mode ( 300 ns / 0.8473 * 200 pF), to be 1.77 k Ohms. These pull-ups would draw 3.3V / 1.77 k = 1.86 mA each when SCL / SDA is low.
So, theoretically, if this bus has the absolute maximum amount of capacitance on it, this bus should use at least 1.77 k Ohm pull-up resistors, down to 171 Ohm resistors if their maximum low drive strength is 13.5 mA each during SCL/SDA low.
Ideally, the bus capacitance should be lower than the I2C maximum specification, so the formula may give you a higher resistance than this theoretical worst case.
Silicon Labs EFM8 family of 8-bit MCUs is now supported by IAR’s 8051 Embedded Workbench. The EW offers an optimized compiler, a comprehensive debugger, integrated static analysis tools, and more. For documentation, to learn more, or to download please visit https://www.iar.com/iar-embedded-workbench/8051.