8-bit Knowledge Base

    Publish
     
      • Can I boot a C8051 or EFM8 I-temperature microcontroller at -54 degrees C?

        JohnB | 10/304/2017 | 01:38 PM

        This question, and others like it, are frequent arrivals in the applications engineering support queues at Silicon Labs. In nearly every case, they take the form of "Can I run at/with..." where the particular specification only slightly exceeds that which is published in the data sheet.

        Sadly, in all cases, the answer is "No."

        Consider the question above. This customer uses the C8051F580-IQ, which is specified for -40°C to +125°C operation.

        It doesn't seem to be an unreasonable request. After all, there is an entire overclocking movement in the PC world with people using exotic cooling technologies like liquid nitrogen to get x86 processors to run at frequencies well beyond what they are rated by Intel and AMD. Isn't cold a good thing for semiconductors? Could the C8051F580-IQ, in this case, not only boot at -54°C but run faster than its rated 50 MHz?

        Alas, this is a generalization. Not everything on a semiconductor device benefits from being kept cool. Intel CPUs, despite their advanced processing capabilities, are actually rather simple digital devices. Granted, they do have a PLL to generate the high frequency clock and high-speed RAMs that provide the different levels of caching, but these devices are primarily high-density collections of purely digital logic, and, as overclockers have figured out, keeping this digital logic cool permits the attainment of higher levels of performance.

        Why then, isn't this the case for a C8051 or EFM8 microcontroller?

        Unlike an x86 CPU, which is heavily dependent on an external chip set, SPI boot flash, and highly complex PMIC (power management integrated circuit) in order to boot, an 8-bit microcontroller manages this in an entirely self-contained fashion with little external support except for perhaps a voltage regulator.

        This particular customer thought he might be able to boot at -54°C because he did not need any analog functionality and only required UART and CAN to be operational. While he thought that he would not be using any analog peripherals, this is emphatically not true. The C8051F580 boots from the internal oscillator in all cases, and this is an analog block. The same also applies if he intended to enable the crystal oscillator immediately after beginning code execution.

        Furthermore, while most people don't think of RAM as analog, it is a hard block that is compiled and placed on the chip to facilitate die layout, not operation at a particular temperature. The same also applies to the flash, which comes as pre-built hard blocks in the particular sizes needed. Even to exit reset, the MCU depends on an analog block, a comparator that is part of the power-on reset circuit.

        Shouldn't these analog blocks also benefit from being kept cool like digital logic? Maybe, maybe not. All transistors exhibit marginal behavior at temperature extremes. Analog blocks are comprised of transistors that often make use of custom sizing in order to achieve the desired behavior.

        Consider, again, the comparator used in a power-on reset circuit, which must go active when a particular voltage threshold is reached. This block has to be simulated to be sure it behaves in the desired fashion over the rated operating temperature and voltage range, and this impacts the parameters of the particular transistors from which it is built. A happy medium must be found for these parameters to guarantee this and provide some extra margin for the inevitable shifts that occur in fabrication as the manufacturing equipment ages and as the photomasks used for each layer of the die deteriorate over their useful lives.

        Just as overclockers tend to think that their processors have huge amounts of margin because Intel and AMD offer variants with clock frequencies that might range from 2.0 to 4.4 GHz, some microcontroller users think there is similar margin built into their 8-bit devices. After all, while the C8051F580-IQ has a rated ambient temperature range of -40°C to +125°C, the datasheet specifically lists an "Ambient Temperature under Bias" parameter with a range of -55°C to +135°C in the Absolute Maximum Specifications table. Doesn't this mean the device can operate at these extremes of temperature, if only for a short amount of time?

        The answer here is unequivocally "No." As the note in the C8051F580 datasheet makes abundantly clear, "this is a stress rating only and functional operation of the devices at those or any other conditions above those indicated in the operation listings of this specification is not implied. Exposure to maximum rating conditions for extended periods may affect device reliability." In other words, the device can survive transients of temperature, voltage, or current that do not exceed the absolute maximums. There is, however, no guarantee of proper functionality when this happens.

        In summary, specifications really are absolute. While a single device or even a particular batch of devices may work fine when exceeding a particular operating parameter, there's no guarantee that this will be the case weeks or years in the future for a device that has been newly purchased or has otherwise been functioning in a system without incident.

      • 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')
        else:
            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')
        else:
            raise RuntimeError("HidSmbus: Unsupported OS")

         

         

        These Linux libraries .so.1.0 files can be found in USBXpressHostSDK for Linux, if you have download 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 bootloader mode, then try the following command with specified serial port:

         

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

         

        AN945-UART-Bootloader-Linux.png

      • Cx51 Variable-length Argument List Size

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

        Question

        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?

        Answer

        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.

         

        Cx51_MAXARGS.png

         

        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)

      • Center Pad Connection

        Alan_S | 10/275/2017 | 02:59 PM

        Question

        The part I want to use has a center pad on its package. What should I connect this to?

        Answer

        The pinout diagram in the device's datasheet will indicate what this pad should be connected to. For example, Figure 5.2 of the CP2102N datasheet shows that the center pad should be connected to GND.