8-bit Knowledge Base

      • 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.

      • Center Pad Connection

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


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


        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.

      • VCPXpress example code does not work as expected on the UB1 STK

        marao | 07/201/2017 | 10:48 AM


        When using example EFM8UB1_VCPXpress code on a SLSTK2000A EFM8UB1 STK to create a USB-to-UART bridge , COM port on Tera Term could not be connected or was not seen. Why is this happening?



        This is a known issue and Silicon Labs is working on updating the library. 


        When a device enumerates as a CP210x, the host asks the device a string of questions, which are either ACK'ed or NAK'ed (till the information is made available by the device). If the device is NAK-ing, the host will continue to wait for the information from the device and we are in a sense "stuck". 

        The USB traffic for this particular case shows that there is a command(lock_byte) causing a continuous stream of NAK's from the device. The device was not being recognized as a COM port in teraterm because the device had not fully enumerated in this case. This does not happen in case of a CP210x device, because all the commands are handled in the library source. The VCPXpress is for devices that behave as CP210x, hence parameters such as lock byte, gpio configuration of the CP210x device etc have no meaning. When such information is asked for by the host, the device is supposed to stall the host. The host will then continue to handle other commands sent and the device will be finally enumerated.


        There is an error in the VCPXpress library code that was causing this issue. This change needs to be done in a lot of APIs within the library source and will need to undergo testing which is current underway. There is a patch that fixes the issue mentioned above (which is attached to this article). This has to be replaced in the library in the SDK. A point to be kept in mind is that this is a WIP library and we will be rolling out the fixed version soon. 

      • The role of STALL handshake packet in USB transfer

        yucheng | 06/169/2017 | 09:42 PM


        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.



      • Flash size for USB to serial example on EFM8UB1

        jstine | 03/60/2017 | 06:55 PM


        What flash size of EFM8UB1 is required to run the USB to serial example?


        The example provided in Simplicity Studio compiles to 11,576 bytes (release mode, optimized for size), so the 16k part is required.

      • 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:






      • 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.

      • ToolStick Base Adapter dimensions

        jstine | 11/316/2016 | 11:27 AM


        What are the physical dimensions of the ToolStick Base Adapter?


        The ToolStick Base Adapter is 2 1/4" long (plus 3/4" for the USB connector), 1 1/8" wide, and 3/8" tall (with connectors).  The board thickness is 1/16".

      • How to get the information of usb devices under windows

        yucheng | 09/270/2016 | 02:45 AM

        Sometimes the user need to get the complete usb information (PID/VID etc) within software under Windows system just like the lsusb command under linux system.

        In fact, Windows also have provided some function interface to get the device information as illustrated in the Device Manager.



        SetupDiGetClassDevs function

        The SetupDiGetClassDevs function returns a handle to a device information set that contains requested device information elements for a local computer.

        Please reference the link as below for the detailed Syntax/Parameters/Return Value/Remarks information of this interface.



        And please also reference the attached example code, it listed all of the usb devices in the PC, and also extracted the PID/VID/Interface information for further implementation. 

        For example,
        Run USBInfo.exe directly with CP2108 plug-in for checking, the detailed information of CP2108 interface as below, 



      • What's the role of billboard device in Type-c solution

        yucheng | 09/270/2016 | 02:44 AM

        There are 2 main functions in Type-c. One is power negotiation, 2nd is alternate mode.

        The USB Billboard Device Class definition describes the methods used to communicate the Alternate Modes supported by a Device Container to a host system. This includes string descriptors that can be used to provide support details in a human-readable format.

        If a device fails to successfully enter an Alternate Mode within tAMETimeout then the device shall minimally expose a USB 2.0 interface (USB Billboard Device Class) that is powered by VBUS for popping-up message window to the user.