8-bit Knowledge Base

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

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

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

        Question

        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?

         

        Answer

        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.

         

        STALL_win.png

         

        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.

         

        STALL_mac.png

      • Flash size for USB to serial example on EFM8UB1

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

        Question

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

        Answer

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

      • SPI最大传输速率

        yucheng | 01/13/2017 | 03:09 AM

        问题

        SPI作为master或slave时可以达到的最大传输速率是多少 ?

        答案

        SPI最大传输速率受以下几个条件影响:

        1. SPI的最大时钟频率
        2. CPU处理SPI数据的能力
        3. 输出端驱动能力(PCB所允许的最大信号传输速率)

         

        SPI的最大时钟频率

        一般情况下,SPI模块的最大时钟频率为系统时钟频率的1/2。虽然SPI的传输速率主要受限于CPU处理SPI数据的能力,但在同另一个非常高速率的SPI设备通讯时,SPI的最大时钟频率将有可能制约其传输速率。

         

        CPU处理SPI数据的能力

        通常情况下,考虑到系统中CPU有可能需要处理其他任务,以及对所接收SPI数据的具体运算处理方法,CPU处理SPI数据的能力将影响到整体的传输速率。

        例如,系统在收到SPI数据后只是作简单的累加。如果当前SPI模块的时钟频率是1/2系统时钟频率,接收每一个SPI byte将需要16个系统时钟周期。那么在下一笔SPI数据接收到之前CPU有足够的时间来处理当前数据,此时SPI的最大传输速率即为系统时钟的1/2。

        接下来考虑另外一种情形,假设CPU有50%的时间用于处理其他任务,同时对所接收到的每byte SPI数据,需要100个系统时钟周期来作运算处理。每接收1 byte SPI数据,CPU需要100个时钟周期来作处理,同时需要100个时钟周期来处理其他任务,因此总共需要消耗200个系统时钟周期。用公式表达如下:

        200 *Tsysclk = 8 * Tspiclk;

        spiclk = sysclk/25;

        因此,在这个例子中,我们可以看出SPI的最大传输速率由CPU处理SPI数据的能力所决定。

         

        输出端驱动能力

        最后要考虑的因素是输出节点的驱动力。PCB上的微量电容和器件引脚的输出阻抗相结合,将会形成一个低通滤波器,限制设备间信号的传输速度。通常该滤波器的截止频率可以近似为:

        Fmax = 1 /(2 × π × Rdrive * Ctrace);

        其中Rdrive是所驱动的最大阻抗值,Ctrace表示输出节点所驱动的所有微量电容的总和。

        在固定阻抗条件下,电路的微量电容将成为制约SPI传输速率的因素。系统中如果设备间的距离非常短(Ctrace较小值),那么CPU的处理能力或SPI的时钟频率将是主要限制因素。如果系统中总线上有多个SPI设备,同时设备间的连线很长(Ctrace较大值),那么输出驱动能力将制约SPI的传输速率。

      • USBXpress/Direct Access device problems in Android OS

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

        Symptoms

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

        Diagnosis

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

        Solution

        Try adding control transfer commands with the data mentioned above before the bulk transfer commands.  For instance:

         

         

         

        connection.ControlTransfer(0x40,0x00,0xFF,0xFF,OBuf,0,0);
        connection.ControlTransfer(0x40,0x02,0x02,0,OBuf,0,0);

         

      • Legacy USB Device Detection by Type-C

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

        Question

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

        Answer

        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

        Question

        What are the physical dimensions of the ToolStick Base Adapter?

        Answer

        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.

        1.png

         

        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.

        https://msdn.microsoft.com/en-us/library/windows/hardware/ff551069(v=vs.85).aspx

         

        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, 

        1.png

         

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