[ChipworkX] Problem with Serial-USB-Converter SiLabs


I tried to get a Serial-USB-Converter working on my ChipworkX-System. I tried my FTDI-Converter without any problems (thats a real Serial-USB-Converter).

Afterwards I tried to use a device (optical interface to a Smart Meter and a RS485 converter with the same chip) to get it working with my board - but it does not work. The devices have a “Silicon Labs CP210x USB to UART Bridge”-Chip inside. The PC knows it as this type and offers a COM-Port. I tried sending/receiving with PC without any Problems (300 Baud, 7 databits, 1 Stopbit, Even Parity, No Handshake).

After connecting the SiLabs-Device to the ChipworkX and tried sending with the same method as the FTDI-Chip, but an other device (the device is added the same way as in the sample at GHI Librabry Documentation). But this does not work! I can see, that the optical device is sending some data (infrared is sent), but I do not get data at the other device.

What could that be? Is there a problem with the baudrate (300) using SiLabs? Does it not work with the choosen settings? I don’t know what to try next to get it working…

Thanks in advance

Regards from Austria, Andi

I assume you’re using this converter as a USB Host connected device. Did you check the library API notes? There’s a specific example that talks about Silabs devices - it is not always presented as a serial endpoint, so there’s an example of forcing it to connect.

I doubt the team tested it at 300 baud or if it is supported. It was meanly used with GPS receivers.

I know, I “force” it to be a SiLabs device after Checking VID and PID! Thats no problem. It also sends something out (I see infrared LED flashing in webcam), but I don’t know what!

Is there a possibility to test that? I have got not the equipement. Our is it a possibility that somebody looks at the code if there is anything wrong with sending at 300 Baud? I’ve tried various things, but do not get the SiLabs device running. I need to send at 300 Baud, because the Smart Meter does not react on other Speeds.

Or any other suggestions what to try?

Thanks, Andi

You could perhaps jumper TTL UART signals into the other side of the UART, avoiding the USB Host functionality. I don’t know whether UART at 300baud is more robust or more tested than the software side of things, but at least the requirement for it to be working is put back to the chip maker, not the netmf layer.

Hmm I’m sorry, I do not understand what you mean. I have to use the USB-device, because its a out-of-the-box-optical and out-of-the-box rs485 interface with a USB-connector. So using the COM-Port of ChipworkX is not possible.

Or is my english just too bad and I don’t understand?

Thanks for your help, andi

The Silabs chip sits in the USB device. On one side of that chip is the USB connection. On the other side of that chip is a TTL UART connection. You could break open the device, and solder jumper wires directly onto the TTL UART side of the chip, essentially bypassing it. Those wires then connect to a UART of your ChipworX.

Thats not possible. I have to connect it via USB.

I’m sure it’s possible. It’s not necessarily nice, but it is possible.

USB connection <–> Silabs USB-to-UART chip <–> split to RS485 and optical connector (whatever they are)

All you would be doing is bypassing the USB connection and the Silabs chip, you are still using everything else.

Again, whether this then allows you to use a “more tested” code or not I can’t answer, but it does bypass the USB Host code and go back to using a UART on the processor (which is typically more tested because the vendor wouldn’t offer it as an option if they didn’t test it)

It’s a requirement, that I use USB. The devices provided must be used as they are, because they are not only used once here…

That it is technical possible - sure! That would be no problem. But the usage of more of these devices is the problem…

So is there a solution using USB? Has anybody got the possibility to test it at 300 baud?

Regards, anm

I just checked the exact chip on the device - its a “Silabs CP2102 DCL06A 1142+” IC - does that help?

Personal thought here: the best way you can test this is to get a pair of Silabs USB-to-RS232 devices that use the same chip and connect one to your PC and one to your CwX, and set them up to use 300 baud. There aren’t many devices these days that talk at 300 baud. Is it possible that the default baud rate can be increased?

Actually, can you elaborate on the other pieces of the USB cable, specifically the UART-to-optical and UART-to-RS485 portion of it? Perhaps you could design your own?

And while we’re at it, can you show us a sample code of how you set up the connection? I have a couple of CP2102 devices coming in the post so when they arrive I may have a way to reproduce this (no CwX but plenty of other Fezzez)

I “minimized” the code…

using System;
using System.Collections;
using GHIElectronics.NETMF.USBHost;
using System.Threading;
using Microsoft.SPOT;
using System.IO.Ports;

namespace Eco2IO {

    class UsbSerialDevice {
        private ArrayList serialUSB_;
        private readonly object _serial_usb_lock = new object();
        private AutoResetEvent _getDataThreadEvent = new AutoResetEvent(false);

        private System.Text.Encoding enc_ = System.Text.UTF8Encoding.UTF8; //ASCII und UTF8 ist gleich für die gewünschten Zeichen

        public UsbSerialDevice() {
            serialUSB_ = new ArrayList();

            USBHostController.DeviceConnectedEvent += addSerialUsbDevice;
            USBHostController.DeviceDisconnectedEvent += removeSerialUsbDevice;

            Thread getThread = new Thread(getSerialUsbDataThread);

        public void addSerialUsbDevice(USBH_Device device) {
            if (device.TYPE == USBH_DeviceType.Serial_FTDI) { //WORKS!! (real serial to usb)
                USBH_SerialUSB serialUSB = new USBH_SerialUSB(device, 300, Parity.Even, 7, StopBits.One);

                serialUSB.Handshake = Handshake.None;
                lock (_serial_usb_lock) {
            } else if (device.VENDOR_ID == 4292 && device.PRODUCT_ID == 60000) { //SiLabs CP2012
                USBH_Device silabs = new USBH_Device(device.ID, device.INTERFACE_INDEX, USBH_DeviceType.Serial_SiLabs, device.VENDOR_ID, device.PRODUCT_ID, device.PORT_NUMBER);
                USBH_SerialUSB serialUSB = new USBH_SerialUSB(silabs, 300, Parity.Even, 7, StopBits.One);
                lock (_serial_usb_lock) {

        public void removeSerialUsbDevice(USBH_Device device) {
            if (device.TYPE == USBH_DeviceType.Serial_FTDI || (device.VENDOR_ID == 4292 && device.PRODUCT_ID == 60000)) {
                foreach (USBH_SerialUSB entry in serialUSB_) {
                    if (entry.ID == device.ID) {
                        lock (_serial_usb_lock) {

        private bool isDeviceAvailable() {
            lock (_serial_usb_lock) {
                if (serialUSB_.Count > 0)
                    return true;
                    return false;

        private void getSerialUsbDataThread() {
            while (true) {
                if (!isDeviceAvailable()) {

				lock (_serial_usb_lock) {
					foreach (USBH_SerialUSB device in serialUSB_) {
						device.Write("/?!\r\n"); //my Smart Meter should react on this. Using FTDI it does, using Silabs it does not!                            
                Thread.Sleep(30 * 1000);

ok, I quickly looked at your code and it looks to me at first glance as virtually identical to the sample in the SDK doco. So that’s helpful to know, but I can be no more benefit to you sorry :frowning:

What is interesting is that the same code works for FTDI; What is the reason you can’t use that cable? Does it only do one portion of your system?

Its the requirement to read Smart Meter with RS232 (for this the FTDI is used), with RS485 (Silabs…) and optical (Silabs…). And the devices for RS485 and optical are implemented with this silabs-ICs (unfortunately). I have to use this devices. So I will look at the traffic with a DSO tomorrow in the Lab (or today, here it is 2 AM :))

I hope I’ll get some infos out of looking at it with the DSO.

If anybody has some ideas - please post them!

Regards from Austria late at night ;), Andi


I found out, that the parity isnt correct - why that? I said even parity - but it does always add a “zero” as parity bit…

Regards, andi

The support for silab can be limited. There is actually no documentation on how it works on low level. GHI did some reverse engineering to make it work. The main support and testing was done on 115200 with no changes on parity or bit count. Should you need support for silabs chips you have 2 options, using raw USB to write your own drivers or we can add a specific support for you at a fee. Please contact GHI directly if interested.

I’ll write a wrapper for it, but it would be great if you mention it in the GHI Electronics NETMF Library
USBH_SerialUSB Class Documentation. I will post a solution here if it works…

Regards, andi