8-bit Knowledge Base

      • Can we use EFM8 STK on board JLink debugger to program the C8051 device?

        delu | 11/312/2017 | 08:56 PM


        Can we use EFM8 STK on board JLink debugger to program C8051 device?


        Yes, this is possible.

        The steps as follows:

        1. Upgrade the adapter firmware on the EFM8 STK to latest version 0v15p3b761. Two ways to update and verify the adapter firmware:

        a. Connect the STK to PC and start Simplicity Studio V4, Select you STK in device view. Clicking on Adapter Firmware Version->Change->Adapter Configuration, that allows you to update the Jlink adapter's firmware. You can see firmware version next to "Adapter Firmware Version" in launcher view.



        b. Start the Simplicity Commander and connect Jlink adapter of STK, under the Kit->Update Kit->Installation package, user can select fimrware package by clicking on Browse button, Then click on Install Package button to install it. The firmware version is displayed on the Kit->Kit Information->Firmware version.



        2. Connect the VTARGET, C2D, C2CK and GND signals of the Debug Connector on the EFM8 Starter Kit to the target .


        3. Make sure target MCU powered up.

        4. Change STK Debug Mode to Debug Out. Both Simplicity Studio and Simplicity Commander can do this job.

        Simplicity Commander:


        Simplicity Studio:



        5. Using Segger JLink tool to program the blinky hex image file to C8051F380 and run the code: 

        SEGGER J-Link Commander V6.17a (Compiled Jul 10 2017 17:13:16)
        DLL version V6.17a, compiled Jul 10 2017 17:12:41
        Connecting to J-Link via USB...O.K.
        Firmware: Silicon Labs J-Link OB compiled May 19 2017 10:18:02
        Hardware version: V1.00
        S/N: 440033288
        VTref = 3.250V
        Type "connect" to establish a target connection, '?' for help
        J-Link>device C8051F380
        Please specify target interface:
          C) C2 (Default)
        Specify target interface speed [kHz]. : 1000 kHz
        Device "C8051F380" selected.
        Connecting to target via C2
        DevID, DerivID: 0x28, 0xD0
        Core: CIP-51 (8051 compatible)
        Device series: C8051F38x series device
        CPU supports 4 code breakpoints
        Flash infos: 512 byte sectors, 126 sectors, all sectors unlocked
        Memory zones:
          C  CODE
          I  IDATA
          D  DDATA
          X  XDATA
          DSR  DSR
          C2  C2
        8051 (EFM8) identified.
        J-Link>loadfile F38x_Blinky.hex
        Downloading file [F38x_Blinky.hex]...


        Note: The Flash Programmer integrated in the Simplicity Studio has problem to program C8051F380 through the EFM8 STK on-board JLinker debugger. So here we choose Jlink commander tool to program C8051 devices.

        Please also check the Segger website to see what C8051Fxxx part was supported by the JLink debugger.


        Related KBA:

        How to use EFM8 Starter Kit on-board debugger to debug an external EFM8 device

        How to use EFM32 Starter Kit on-board debugger to debug an external EFM8 device

        Using the USB Debug Adapter to debug EFM8 on custom boards and EFM8 STKs



      • Do I need enable crossbar if a port pin work as general purpose GPIO

        delu | 11/312/2017 | 08:43 PM


        For 8-bit MCU like EFM8UB2, a port pin isavailable on crossbar, do I need to enable crossbar if a port pin work as general purpose GPIO (non peripheral mode)?


        For port pin is available on crossbar, if you need to control it's level through the Px.x latch value, you need to enable the crossbar.

        Take the EFM8UB2 as example, you could see what port pin was available on crossbar in figure 11.4 on page 83 of the reference manual.

        The port I/O cell block diagram shown in figure 11.2 on page 79 of reference manual.

        From the below diagram, we can know once the crossbar is disabled, the Px.x latch value wont' take effects on port pin.





      • Silicon Labs 8-bit (C8051Fxxx and EFM8) MCU GPIO type.

        delu | 11/312/2017 | 08:37 PM


        What is the difference of GPIO structure on Silicon Labs MCU families.


        5V tolerance of GPIO pins on Silicon Labs MCU families as follows

        Type A: 
        • Pins are 5V tolerant across the normal operating power supply range.   When the power supply is 0V, the pins can tolerate 3.3V indefinitely, and they can tolerate 5V for brief periods (such as a hot-plug situation) without additional pin leakage.  Long-term exposure to 5V while the chip is unpowered may result in performance degradation or failure.
        • Devices: F30x, F326.etc

        Type B:

        • Pins are tolerant of the IO power supply voltage plus 2.5V, so they are 5V tolerant with a 3.3V supply.  When the pin voltage rises more than 2V above the supply, the leakage currents from the pin to the supply and from the pin to ground will increase with voltage.  When the power supply is 0V, the applied pin voltage can be as high as 3.3V at room temperature with moderate leakage; but at that voltage, the leakage can be very high at elevated temperature.

        • Devices: EFM8UB1, C8051F86x.etc

        Type D:

        • Pins cannot exceed the IO power supply voltage, which can be up to 3.3V.  The pin includes an ESD protection diode to the power supply, so the pin leakage will increase exponentially if the pin voltage exceeds the power supply voltage by more than 0.5V at room temperature; therefore they are not 5V tolerant under any conditions.
        • Device: EFM8SB1, C8051F37x/39x.etc
      • Leakage current affects ADC measurement result

        delu | 11/312/2017 | 08:25 PM

        There is a statement in EFM8LB1 spec that pin leakage current is in the range of [-1.1 4] uA . Does this leakage current affects ADC result of external signal?

        Correct, the leakage mainly dominated by the ESD protection circuit for the port structure. It may flow in or out of the device. The leakage current is strongly sensitive to the temperature.
        Let us assume 100nA leakage, and output impedance for source signal to be measured is 10k ohm. Then the measurement error caused by the leakage likes an offset error of ADC result. This example gets 100nA*10kOhm = 1mV voltage offset (measured) on the pin.
        Under condition that ADC is configured as 2.5V VFS and 12-bit resolution. Then we have 1 LSB equals to be about 2.5V/4096 = 610uV
        Then the 10k Ohm resistance of external source signal to be measured would see 1 LSB offset error as 1mV>610uV.

        Related KBA: Comparator Input Leakage

      • Pin width: EFM32HG TQFP-48 package

        BrianL | 11/305/2017 | 11:16 AM


        What is the width of the pins on the TQFP-48 package on EFM32HG devices? This is not listed as a dimension in tables 4.4 (package specifications).


        Firstly, page 59, Figure 5.1 does show the recommended landing patterns for this device's pins as 1.6 x 0.3 mm. So, it's reasonable to expect the pin width to be, at most 0.3 mm.

        In table 4.4, we can also derive the pad with by examining the distance between the edges of adjacent pins (0.2 mm, T, U, V, Z) and the pitch width (the distance between the centers of pins (0.5 mm). The pitch width should be equal to (1/2 pin width) * 2 + pin separation. So pin width + 0.2 mm = 0.5 mm, so pin width equals 0.3 mm.


        Examining a TQFP-48 device here with a microscope, I observe that the pins indeed do seem larger than the gaps between them, so 0.3 mm should be the correct number for the pin width, and 0.2 mm for the pin gaps.

      • Measuring Temperature with EFM8LB1

        BrianL | 11/305/2017 | 11:13 AM


        I am measuring the internal temperature sensor with the ADC. I then use the formula from the appnote (https://www.silabs.com/documents/public/application-notes/AN929.pdf) to calculate the temperature, using the internal temp sensor calibration reading.


        ((ADC Temp sensor measurement) - (stored Cal value) / 28 = Temperature C


        However, I am getting odd results. For example, I measure 0xE84 from the temperature sensor. The cal value stored in flash at 0xFFD4-0xFFD5 reads back 0x10C7A. This results in the following formula.


        (0xE84-0x1C7A) / 28 = -127.6 C


        This can't be right since the measurement is being performed at room temperature. What is going on here?


        The temp sensor cal value is taken with the internal voltage reference at 1.65 V, and the ADC set to 14-bit mode with a PGA gain of 1 (rather than 0.5). The settings for taking a temperature sensor reading must be identical, or the measured value will be on the wrong scale compared to the temperature sensor.


        Make sure that the ADC is set to 14-bit mode, 1.65 V internal reference, and PGA gain of 1 (0.5 is the default). As a result, our previous measurement at the same temperature now reads 0x20A9.


        The resulting formula is then:


        (0x20A9 - 0x1C7A) / 28 = 29.2 C


        This is an expected result for a measurement near room temperature.

      • How to use EFM8 UART Bootloader on Linux

        Jiehui | 10/296/2017 | 02:17 AM

        EFM8 Factory Bootloader AN945SW contains all EFM8 bootloader images with UART, USB or SMBus interface. The source of the efm8load tool, a python script efm8load.py is also included under /Tools/Source folder. Since Python is a cross-platform language, and therefore the script can run on a Linux system.


        However, if run the efm8load.py on Linux directly, it will throw some errors because the current program in hidport.py or smbport.py does not support Linux. It is necessary to make slight modification by loading associated libraries for Linux as below on both scripts


        In hidport.py:


        # Load HID shared library using ctypes
        if sys.platform == 'win32':
            _DLL = ct.windll.LoadLibrary('SLABHIDDevice.dll')
        elif sys.platform == 'darwin':
            _DLL = ct.cdll.LoadLibrary('libSLABHIDDevice.dylib')
        elif sys.platform.startswith('linux'):
            _DLL = ct.cdll.LoadLibrary('./libslabhiddevice.so.1.0')
            raise RuntimeError('HidPort: Unsupported OS')



        In smbport.py:


        # Load HID shared library using ctypes
        if sys.platform == 'win32':
            _DLL = ct.windll.LoadLibrary("SLABHIDtoSMBus.dll")
        elif sys.platform == 'darwin':
            _DLL = ct.cdll.LoadLibrary("libSLABHIDtoSMBus.dylib")
        elif sys.platform.startswith('linux'):
            _DLL_prev = ct.CDLL("./libslabhiddevice.so.1.0", mode=ct.RTLD_GLOBAL)
            _DLL = ct.cdll.LoadLibrary('./libslabhidtosmbus.so.1.0')
            raise RuntimeError("HidSmbus: Unsupported OS")



        These Linux libraries .so.1.0 files can be found in USBXpressHostSDK for Linux, if you have downlaod and installed it, then you can copy-and-paste them into the same folder of the python scripts in AN945SW.


        I have also updated the scripts and provided the Linux libraries in the attachment at the end of this article. With the modification above, you can run the efm8load.py on Linux successfully now. Here take EFM8LB1 STK UART bootloader as an example, the STK JLink CDC serial port appears as /dev/ttyACM0 on Linux. If using with CP210x USB-to-UART bridges, the serial port shows as /dev/ttyUSB0 instead.


        To load the application image into the MCU, firstly let the EFM8 device enter UART bootlaoder mode, then try the following command with specified serial port:


        sudo python efm8load.py -p /dev/ttyACM0 filename.efm8



      • Cx51 Variable-length Argument List Size

        Jiehui | 10/282/2017 | 04:31 AM


        How to can I change the number of bytes reserved for function with a variable-length argument list when using 8-bit MCUs with Cx51?


        By default, the C51 compiler reserves 15 bytes for passing arguments to functions with variable-length argument list for SMALL and COMPACT memory model, and 40 bytes for LARGER memory model.


        User can use the MAXARGS(n) compiler directive to change the number of bytes reserved.


        To do this in Simplicity IDE, here as an example, if 24 bytes is required for the variable-length argument list, you can use the MAXARGS(24) for the Keil 8051 Compiler setting as the picture below showing, and then re-build the project again.




        For more information on Cx51 Variable Length Argument Routines, please click here.


      • Using the DAC RSTMD retention feature of the EFM8LB1 and EFM8BB3 devices

        MitchC | 10/275/2017 | 03:03 PM

        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.

      • Using the Port I/O PINRSTMD feature of the EFM8LB1 and EFM8BB3 devices

        MitchC | 10/275/2017 | 03:02 PM

        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)