8-bit Knowledge Base

      • USBXpress/Direct Access device problems in Android OS

        MitchC | 12/365/2016 | 10:23 AM


        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:






      • DAC usage in applications when 0V output is required at power-on

        MitchC | 12/365/2016 | 10:22 AM


        I wish to use the EFM8/C8051 voltage DAC in an application, but I require that the output voltage to be 0 V at start-up (as is possible with some dedicated I2C DAC devices).  Is this possible using the EFM8/C8051 devices?


        Though it is not possible for the GPIO pins to power on at 0V due to device reset values, it is possible to ensure that the pins assigned to DAC functionality power up at ~0 V by using an appropriately sized external pull-down resistor.


        By default, all of the GPIO pins, including those that are accessible to the crossbar and those that aren't, have weak pull-up transistors. These weak pull-up transistors are all affected by the state of the WEAKPUD pin (XBRn.7), and are enabled on reset.  Thus, there will be an unavoidable period of time before firmware re-configures the pins where the GPIO pin voltage will be equal to VDD/VIO.  Because of the reset conditions, it is not possible to ensure that the DAC pins power-on at zero volts.  After reset, these pins can be switched to analog mode by clearing the corresponding bits in the PxMDIN register and setting the associated bit in the Px latch register soon after reset. This will disable the high and low drivers, as well as the weak pull-up transistor for these pins.


        To determine the size of the needed pull-down resistor for the desired power-on voltage for the pin, you must calculate the equivalent series resistance (ESR) of the internal pull-up transistor.  The ESR value of the weak pull-up transistor is dependent on the value of VIO (or VDD if the device has no separate VIO power domain). You can calculate the ESR of this pull-up based on the datasheet specification for Weak Pull-Up Current (weak pull-up on, Vin = 0V) and VIO. Assuming VIO = 3.3V, the ESR = 3.3V/20 uA = approximately 165 k-ohms. Here is a link to a knowledge base article that discusses the ESR of the weak pullups:

        For example, to keep the DAC pin below 2 V at power-on in this case, you would need to use a pull-down resistor at least as strong as 253 k-ohms. Similarly, using a 1K pull-down in this case would yeild an approximate power-on voltage of 20 mV for the selected pin.


        Please note that on the EFM8LB1 and EFM8BB3 devices, it is possible to set the DAC output to persist through any reset except a POR by setting the RSTMD bit in the DACnCF0 register. Similarly, "firmware may configure the port I/O, DAC outputs, and precision reference to maintain state through system resets other than power-on resets. Setting the RSTMD bits in the DACnCF0 registers will cause the DAC output voltage and precision reference to persist through all resets except for power-on resets. 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." (EFM8BB3 Reference Manual section 9.3.1, page 72). Upon, POR, however, all register and RAM settings will return to their default/reset values.


        Because the GPIO pins on these MCUs are multi-function I/O and not exclusively dedicated to DAC output, the port I/O configuration is defined by this weak pull up and default I/O configuration.  This may help explain why the pins do not power up at 0V as may other dedicated DAC IC devices.

      • Why does the EFM8LB1 temperature sensor calibration use the 1.65 V internal voltage reference?

        MarkDing | 12/363/2016 | 05:34 PM


        Why does the EFM8LB1 temperature sensor calibration use the 1.65 V internal voltage reference?


        There are multiple reasons for using the 1.65V reference.


        The three internal references all have similar accuracy, since the accuracy is dominated by the bandgap reference that is used for all three of them. However, there is no way to directly measure the 1.65V reference; it must be inferred by applying a precise input voltage to the ADC and measuring the output codes using the 1.65V reference.  This adds some additional uncertainty to the measurement.  The 1.65V reference is also a little lower, so its measurement is more affected by ADC noise.  Finally, there is some rounding error in the reported accuracy because we round the result to the nearest 10 mV.  For these reasons, the specifications on the 1.65V internal reference are slightly relaxed compared to the other two references.


        The 1.65V reference has essentially the same temperature performance as the other two references, it settles quickly, and it does not require an external pin. These attributes make it more desirable for use with the temperature sensor.  We wanted the temp sensor to be completely self-contained on the die to eliminate any interference from other blocks on the chip or from the PCB.  The 1.2V and 2.4V references can be used for biasing the comparators or the DACs on LB1, which could have resulted in comparator or DAC noise being coupled into the temperature measurement.  Also, in some applications, the firmware may put the device into a low-power state when the temp sensor is not being used, and the 1.2V/2.4V reference has a very long startup time.  This will substantially increase the power associated with one set of temperature measurements, since the reference will need to be powered up for several ms before its output is stable.  More likely, the 1.2V/2.4V reference would just be left on all the time.


        The accuracy of the 1.65V reference is built in to the accuracy for the temperature sensor, and it was exclusively used for all of the temperature sensor characterization.  This reference can only be used by the ADC.  By using the 1.65V reference for the temperature sensor, we free up the 1.2V/2.4V references for use by other resources, or we give the system the option to avoid using that reference at all, and using the pin for something else.

      • Unable to enter EFM8 bootloader by initiating a reset from software

        PhillipB | 12/363/2016 | 05:28 PM


        Per AN945, it is possible to start the EFM8 bootloader by performing a SW reset with a value of 0xA5 in register R0. However, when I write a value of 0x10 to RSTSRC, nothing happens and my code just keeps running.  Why isn't this working?


        As described in application note "AN945: EFM8 Factory Bootloader User Guide" and the "How does the EFM8 device enter bootloader mode?" knowledge base article, you can enter the factory bootloader "on demand" by setting the signature value 0xA5 in R0 in Bank 0 and then initiating a SW reset. However, SFRs cannot be written indirectly, so you must write to RSTSRC using direct addressing to successfully initiate a SW reset.


        As discussed in the "Rainbow Blinky Example" section in AN945, a special "blinky" example is provided in the AN945SW archive linked from the 8-bit App Notes page (www.silabs.com/8bit-appnotes) - also available within Simplicity Studio - that demonstrates how to enter the factory bootloader on-demand from within application firmware.

      • VDD Monitor Threshold Setting

        yucheng | 12/356/2016 | 10:54 AM


        How do I set the VDD monitor threshold?


        Some MCUs have two VDD Monitor levels that can be selected: low threshold monitor lever and high threshold monitor level. Examples of these devices are C8051F500, C851F530, C851F540, and C851F550.


        Silicon Labs strongly recommends that the VDD Monitor is always left in the low threshold setting. The reason is that the output of the internal voltage regulator is calibrated by the MCU immediately after any reset event, and the output of the un-calibrated internal regulator could be below the high threshold setting of the VDD Monitor. The MCU will receives a non-power on reset, VDD Monitor will keep the MCU in reset until a POR occurs. A POR will force the VDD Monitor to the low threshold setting which is guaranteed to be below the uncalibrated output of the internal regulator. The device will then exit reset and resume normal operation.


        However, if the system clock frequencies greater than 25 MHz, the VDD monitor level should be set to the high threshold to prevent undefined CPU operation. The high threshold should only be used with an external regulator powering VDD directly, not the internal voltage regulator.  The figure below illustrates the recommended power supply connections. The VDD and VDDA voltages must be 2V or higher and greater than the VDD monitor high threshold.




        The electrical characteristics about VDD / VDDA voltage and reset threshold can be found within the Electrical Charateristics section of the datasheet. An excerpt is shown below.




        When programming the Flash in-system, the VDD Monitor must be set to the high threshold setting. For the highest system reliability, an external voltage regulator should be used. If this is not possible, the time the VDD Monitor is set to the high threshold setting should be minimized.

      • Legacy USB Device Detection by Type-C

        yucheng | 12/356/2016 | 10:48 AM


        How do I enable the legacy USB devices to be detected by a Type-C source ?


        The general concept for setting up a valid connection between a Source and Sink is based on being able to detect terminations residing in the product being attached. To aid in defining the functional behavior of CC, a pull-up (Rp) and pull-down (Rd) termination model is used – actual implementation in hosts and devices may vary, the Figure below illustrates the model.

        Initially, a Source exposes independent Rp terminations on its CC1 and CC2 pins, and a Sink exposes independent Rd terminations on its CC1 and CC2 pins, the Source-to-Sink combination of this circuit configuration represents a valid connection. As illustrated in the Figure above, only one CC pin is connected through the cable to establish signal orientation.

        For example, below is the functional mode of an adapter that connect a Type-C source to a legacy device port. This adapter has a USB Type-C plug on one end plugged into the Source and either a USB Standard-B plug, USB Micro-B plug, USB Mini-B plug, or a USB Standard-A receptacle on the other end. The Pin A5 (CC) of the USB Type-C plug shall be connected to GND through a resistor Rd, and the recommended value of Rd in the Type-C specification is 5.1 kΩ ± 20%.


        After connecting the legacy device to the Type-C source through the adapter, the source can detect the pull-down on the CC pin because of Rd, and then the source will turn on VBUS and VCONN.

        Below is a prototype of the adapter to demonstrate the connection between a Type-C Source and a Legacy device port.

        Connect the Pin A5 (CC) of the USB Type-C plug to GND through a resistor Rd (5.1 kΩ ± 20%), then connect Pin A6/A7 of the Type-C plug to D+/D- of USB Micro-B Plug.

        All VBUS pins (A4 B4 A9 B9) and all Ground return pins (A1 B1 A12 B12) shall be connected together within the USB Type-C plug.

        Connect a legacy device to the Type-C source through the adapter, it can be detected correctly, and also works well with the Type-C source.

      • Flash Erase Cycle Time

        Stephen | 12/347/2016 | 04:02 PM


        Is the Flash Erase Cycle Time in the datasheet per page or for the entire device?


        The flash erase cycle time specification in the datasheet is per page.

      • C8051F9xx operating voltage range

        marao | 12/347/2016 | 03:38 PM


        Can this device work from 0.9 - 3.6 V? Why do you mention two specific operating ranges: 0.9-1.8 V  and 1.8 - 3.6 V?


        The C8051F9xx devices were designed to be powered from unregulated batteries, and no commonly-used battery cells or combinations of cells provide voltages between 1.6 V and 1.8 V at any point during their useful operating life. The C8051F9xx devices are designed to provide full analog and digital performance and minimum power consumption at an internal supply voltage of 1.8 V, so we provide two distinct operating modes with different pin connections and external components, based on whether the battery voltage is above or below 1.8 V.


        Most of today’s low-power products use alkaline, carbon-zinc, silver oxide, NiCd, or NiMH battery chemistries, all of which have cell voltages that range from 1.2–1.6 V when fresh, and from 0.9–1.0 V at the end of their useful life. Two of these cells in series will provide a supply voltage between 1.8 V and 3.2 V; therefore, the C8051F9xx “Two-Cell Mode” supply voltage range of 1.8 V to 3.6 V can accommodate two standard battery cells, a single lithium coin cell (having an operating voltage range of 3.0–2.0 V), and regulated supplies ranging from 2–3.3 V, ±10 %.


        One feature that separates the C8051F9xx family from all other general-purpose, 8-bit microcontrollers is the ability to operate from a single-cell battery at voltages down to 0.9 V. In one-cell mode, some circuit blocks operate directly from the battery; however, the digital core and most analog peripherals are powered from an inductor-based dc-dc converter that generates a supply voltage above 1.8 V. Since the one-cell and two-cell modes require different pin connections and different external components, we specify separate supply voltage ranges for each.

      • C8051F9xx 10-bit ADC performance in one-cell mode

        marao | 12/347/2016 | 03:37 PM


        I am seeing a reduction in SAR10 ADC performance when the device is operating in one-cell mode. What can I do to prevent this degradation?


        Any system that puts large switching activity in close proximity to sensitive analog circuitry has the potential for interference issues, and systems using the C8051F9xx devices are no exception. The switching currents of the dc-dc converter can cause interference with external signals that are used as inputs to the SAR10 ADC. Conversions performed on internal signals (such as the integrated temperature sensor) are usually not affected. In addition to following good engineering practices such as careful board layout of the sensitive signals and the use of an appropriate anti-aliasing filter, there are other steps that can reduce or eliminate the interference.


        1. We recommend the use of the external ground reference option available on the P0.1/AGND pin.
        2. You can use the SYNC bit in the DC0CN register to synchronize the ADC sampling to the dc-dc converter when running the dc-dc converter from its local oscillator.


        Applying averaging to the signal using the SAR10’s burst mode accumulator feature is effective at eliminating any residual noise using this method. Finally, you can manually synchronize the dc-dc converter and SAR10 clocks by ensuring that both clocks are derived from SYSCLK and the SAR10 clock frequency is an integer multiple of the dc-dc clock frequency. In this method, adjustment of the phase relationship between the start-of-conversion signal and the dc-dc clock can prevent the interference.

      • MISRA Standards Compliance in Simplicity Studio for EFM8 and C8051 Devices

        JohnB | 12/347/2016 | 03:34 PM



        What kind of support does Simplicity Studio have for the Motor Industry Software Reliability Association (MISRA) standard for the C programming language? Does the Configurator tool generate MISRA-compliant code? Can the included Keil C compiler for 8051 perform MISRA type checking?



        Simplicity Studio does not provide any integrated support for the MISRA C standards (1998, 2004, and 2012) either in the code generated by the Configurator tool or as an option that can be passed to the Keil 8051 C compiler.


        Customers requiring MISRA support should investigate PC-lint from Gimpel Software. It can be added as a step in the build process by right-clicking on a project in the Project Explorer under Properties → Settings → C/C++ Build → Settings → Build Steps → Pre-build Steps and entering the appropriate command line invocation.