Problem: Couldn't recognize CP2615 as output audio device in Mac OS when configured for 24-bit-only output.
Root cause: The failure to enumerate is due to the Mac OS not tolerating the Interface 3 Alt 1 zero-bandwidth descriptor that is sent by the CP2615 when configured for 24-bit-only operation. The presence of this zero-bandwidth descriptor is not prohibited by the USB standards and is tolerated by other operating systems (Windows, Linux, Android).
Workaround: The problem can be avoided by configuring the CP2615 Audio Out interface for 24/16 bit operation, instead of 24-bit-only. This just adds the 16-bit capability in addition to 24-bit, so there is no loss in the quality. 24-bit source material will still be sent over USB as 24 bits; the only difference is that 16-bit source material will get transmitted across USB as 16 bits, rather than being artificially padded to 24 bits as it would if the CP2615 was configured for 24-bit-only operation. (Padding 16-bit audio to 24-bit does not increase its actual resolution, it just wastes USB bandwidth.)
CP2114 supports record mute by USB host or GPIO pin. CP2114 mutes Record when the USB host sends an Audio Class-Specific request SET_CUR (0x01) to mute the Record audio. In addition, single-pressing the Record Mute button (GPIO.0 by default) will toggle between record mute and unmute states. The Record Mute LED (GPIO.4 by default) is turned on/off accordingly for both control methods.
For Windows machine, the CP2114 device record can be muted with following steps:
The Record Mute LED on CP2114 evaluation board will be toggled as well.
1. Record Mute controlled by Host PC is available for CP2114-B02 revision only. See CP2114 Errata for more information.
2. Record functionality must be enable. User can test with the index 0 of preprogrammed configuration by installing all jumpers of GPIO.5 ~ GPIO.8 on the CP2114 EVB.
Table 3.13 in the CP2615 Datasheet (captioned "Read CP2615 Firmware Revision") depicts an operation available in Configuration Mode to read the Firmware Version Number. How does the value obtained by this sequence map to a CP2615 firmware revision?
The CP2615-A02 firmware version number consists of an ASCII-encoded null-terminated string in the format 2615.x.y.z, where 'x', 'y', and 'z' comprise the firmware version number, and can be one or more characters each. The following table illustrates the data returned by reading 16 bytes from address 0xFFFB on a CP2615-A02 device:
The CP2615-A01 device does not have its firmware version encoded as described above. For the -A01 device, reading 16 bytes from address 0xFFFB returns the following data
For more information, including an alternative means to determine the revision of a CP2615 device (suitable for an end-user situation, e.g. where an app running on the phone or USB host would query the version number), see the KB article "Methods to determine CP2615 revision".
When a CP210x device is connected to the USB host, the host will send a reset signal to the USB device to start the enumeration process. After reset, the host will read the USB device’s information and assign a unique address. If USB host has the driver for the device, the driver will be loaded after enumeration done.
Sometimes the USB enumeration may fail because of bad USB signal quality, incorrect USB driver for the specified VID/PID device, etc. So, it is important to check if the CP210x device is enumerated successfully.
This KBA introduces two methods for checking this.
a) Connect the CP210x device to USB host on Linux.
b) Start a terminal on Linux, type “lsusb” and press Enter. There will be one more USB devices, take the CP2104EK as an example, it named CP210x UART Bridge / myAVR mySmartUSB light (it's a wrong name because of Ubuntu OS, it should be "Silicon Labs CP210x USB to UART Bridge") in my case. The hex value 10c4:ea60 represents VID and PID as shown below. The PID and product name may different if the device is customized.
c) Typing“lsusb -d VID:PID -v” and press Enter, it is “lsusb -d 10c4:ea60 -v” in my case. Then the CP210x device descriptor will be printed out on the screen. By checking the descriptor information we should know if the device has been correctly enumerated. However, if all the data is zeroes (0x0000, for example) or if an error is reported, the device did not properly enumerated.
USBView is a graphical user interface application that enables you to browse USB controllers and connected USB devices on your computer. It displays the information on each of the USB devices (like VID, PID, Product String, descriptors, etc.). The driver for the device does not need to be installed or loaded for USBView to read the information, as the utility uses the low-level USB driver to talk to the device. This is useful when a CP210x is not enumerating because of an incorrectly programmed PID.
You can run USBView by double-click a USBView.exe package on Window. But there is difficulty to run it on Linux. This article will explain how to install and run USBView on Ubuntu.
Gtk3.0 is required for running USBView, you can install gtk3.0 by typing below command and press Enter on terminal.
$ sudo apt-get install libgtk-3-dev
The Ubuntu website provides a .deb package and source code of USBView, you can download it from following link: http://manpages.ubuntu.com/manpages/trusty/man8/usbview.8.html. If you choose to install USBView with .deb package, you can finish it just by double-click .deb package. If you want to install it with source code, you should extract the source code package and enter the extracted directory, then follow three steps to install it.
$ sudo ./configure $ sudo ./make $ sudo ./make install
After installation, you will see the following directory structure.
Running the USBView by typing “sudo ./usbview”, and the graphical display of connected USB devices are shown as below.
Detailed information may be displayed by selecting individual devices in the display.
Some CP210x devices include GPIO pins that can be controlled at runtime. This article discusses reading and writing the latch value of these pins with software on different operating system platforms.
Before connecting to a device, the host must install relevant VCP driver, you can get the appropriate installation package from the link below:
After installing the VCP driver, the CP210x device is recognized by the host when it was plugged in the host USB port. Silabs offers a CP210x Port Read/Write Example application to read/write GPIO latch at runtime.
Taking CP2104EK as testing platform to show how to read/write the GPIO by the CP210x Port Read/Write Example, the CP210x Port Read/Write Example application can be found in AN223SW. Besides, reading AN223 for more information, you can get both of them from the website here https://www.silabs.com/community. we will write value to GPIOs and then read it back by three steps blow.
The CP210x Port Read/Write Example illustrates how the GPIO latch can be read from and written to device by using the CP210xRuntime.DLL. You can develop a custom application using CP210xRuntime.DLL, the functions in this API (CP210xRT_ReadLatch() and CP210xRT_WriteLatch()) give host-based software access to the CP210x device’s GPIO latch using the USB connection.
The CP210x driver has been distributed as part of the Linux kernel since v2.6.12, and GPIO operations also be supported by Linux 4.10.0 kernel or later.
If you are using an older kernel version, please download the latest Linux VCP driver from link below and merge the GPIO operation related source code into your kernel. The .zip package contains VCP driver and example code show how to control GPIOs.
After merging the VCP driver cp210x.c, compile it with make command and install it with command "insmod ". Note that the command "rmmod cp210x.ko" should be executed if VCP driver already exists before installing the driver that support GPIO control.
In the cp210x_gpio_example.c, use the following function to open a CP210x device.
fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY);
Use the function below to read latch, where the third parameter gpioread is a buffer address of one-byte length for storing the read latch value.
ioctl(fd, IOCTL_GPIOGET, &gpioread);
The returned read latch value is represented as follows: bits 0–7: Current latch state, where bit 0 is GPIO0, bit 1 is GPIO1, etc. Up to GPIOn where n is the total number of GPIO pins the interface supports.
Use the function below to write latch, where the third parameter gpio is write latch value.
ioctl(fd, IOCTL_GPIOSET, &gpio);
The write latch value that is supplied in the Data phase represents as follows:
bits 0–7: Mask of the latch state (in bits 8-15) to write, where bit 0 is GPIO0, bit 1 is GPIO1, etc. Up to GPIOn where n is the total number of GPIO pins the interface supports.
bits 8–15: Latch state to write, where bit 8 is GPIO0, bit 9 is GPIO1, etc. Up to GPIOn where n is the total number of GPIO pins the interface supports.
Get more information from AN571.
Compile the application with “gcc cp210x_gpio_example.c”, a executable file “a.out” is generated. Execute it with “./a.out”.
The Mac VCP driver v5.0 or later version supports the GPIO control on the CP210x devices. Download the latest driver here:
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers. We can control the GPIO pins with python.
For using the python, you should install libusb and Pyusb library on your Mac machine, please refer to the following code to write a Python script to control the CP210x GPIO.
import time import usb.core import usb.util PID = 0xea60 VID = 0x10c4 dev = usb.core.find(idVendor=VID, idProduct=PID) if not dev: print "CP2104 was not found :(" exit(1) print "Yeeha! Found CP2104" reqType = 0x41 bReq = 0xFF wVal = 0x37E1 while True: wIndex = 0xffff print "toggling On" dev.ctrl_transfer(reqType, bReq, wVal, wIndex, ) time.sleep(5) print "toggling Off" wIndex = 0x00ff dev.ctrl_transfer(reqType, bReq, wVal, wIndex, ) time.sleep(5)
You can learn more through this video from Lady Ada.
The python script is also suitable for other OS including Window and Linux.
The CP2102N has some additional configuration options that are not available on other CP210x devices. These are displayed in the [Advanced Serial Configuration] tab in Xpress Configurator.
These settings are Windows only and application specific. These settings apply to the SERIAL_COMMPROP structure described here: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddser/ns-ntddser-_serial_commprop
The [Allowed Baudrates] options set the SettableBaud element in this structure, while the [Maximum Baudrate] sets the MaxBaud element in the structure.
The SERIAL_COMMPROP structure describes the capabilities and properties of the serial port, and is returned by the IOCTL_SERIAL_GET_PROPERTIES request, described here: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddser/ni-ntddser-ioctl_serial_get_properties
These settings for this SERIAL_COMMPROP structure have no direct impact on the device's behavior. For example, if the [Maximum Baudrate] is set as 300, an application can still request a higher baudrate, and the CP2102N will happily oblige. It's then up to the application to read the SERIAL_COMMPROP structure and then prevent the user from requesting baudrates that are set to be not supported.
Using CP2105 in Linux embedded platform, when host sends requests to CP2105, but got below error:
"cp210x ttyUSB1: failed set request 0x7 status: -32"
How to interpret the error message?
Table 6 Interface Commands in AN571 lists all API commands that CP210x device supports. Viewing from this Table, request of 0x7 represents SET_MHS command, which is used to set modem handshaking (DTR and RTS lines) states.
The negative error is returned by the underlying call to usb_control_msg() from the cp210x.c driver.
If this function is not successful, a negative error number is returned.
How does CP210x handle the SET_MHS request from host?
For CP210x SET_MHS (0x07) command, as AN571 stated, the DTR and RTS values can be set only if the current handshaking state of the interface allows direct control of the modem control lines.
When the device receives the SET_MHS command intending to change the state of DTR or RTS pin, CP210x device will then check current Flow Control setting in the device and make a different response.
If the hardware Flow Control is currently enabled, then the handshaking lines have been managed by the CP210x device rather than host, the device will not response the current SET_MHS request, and a STALL would be returned.
Question: How can I determine the device revision number for my CP2112 HID USB to SMBus bridge device? Is this information included in the device top marking?
Answer: It is not possible to determine the CP2112 device version is from the top marking alone, as this information is not explicitly encoded in the package marking. To be certain of the device revision, you can query the device over USB and it can return the device version. To do this, you can issue a feature request over USB (Report ID 0x05) and the device will return the part number (0x0C) and the device version. More information on this can be found in application note AN495: CP2112 Interface Specification, section 4.5, page 9:
You can also retrieve the version number from the device over USB using the Silicon Labs HID USB-to-SMBus API, using the function HidSmbus_GetPartNumber(). For more information on doing this, please refer to application note AN496: HID USB-to-SMBus API Specification, section 2.29, page 22:
The above device interrogation techniques are the most reliable way to determine device version number.
What is the right way to determine the revision (A01/A02/...) of my CP2615?
In Section 22.214.171.124 "Special Operations", the CP2615 Datasheet depicts (in Table 3.13 "Read CP2615 Firmware Revision") an operation available in Configuration Mode to read the Firmware Version Number.
In Section 3.2 "iop_AccessoryInfo", AN1139: CP2615 I/O Protocol depicts a "PartID" described as "Encoded part number of the chip (0x1400 for CP2615-A01, 0x1500 for CP2615-A02)."
Reading the version via I2C in config mode requires an external I2C Master, e.g. the special-PID CP2112 on the CP2615 EVB. This method is suitable for a prototyping environment (it's how Xpress Configurator determines the attached device), or in a customer's production-line environment (e.g. the external I2C master can verify the proper device version before programming the config). For this method, the CP2615 must be powered up, but doesn't have to be connected to a USB host. See Knowledge Base Article "Parsing the CP2615 Firmware Version Number" for details on how to interpret this value.
Reading the version via the iop protocol is suitable for an end-user situation, e.g. an app running on the phone or USB host would query the version number before issuing any version-dependent commands (e.g. downloading user profiles, which is only supported on the -A02).