Hi zlogic,

Please refer to Table 19.1 in the EFM8LB1 Reference Manual.

I am not sure why this is not in the datasheet, but it provides the SPI timing parameters.  In master mode, the input setup time is 20 ns.

If you are running the SPI at 36 MHz, your clock cycle is 27.7 ns, and the clock half cycle is 13.88 ns. Consequently, the 20 ns input setup time is longer than the clock half cycle, meaning you are violating the input setup time by running the SPI clock at 36 MHz.

This is why master mode operation is specified for a maximum of 12 MHz. You just got lucky that the one device you are using happens to work at 36 MHz. You may have gotten a device that has slightly shorter pin input delays or you may have mapped the SPI to pins that have shorter input delays than other pins on the device.

Regardless, if you were to attempt to produce such a design, we would expect you would have some fallout because you would eventually have some device where the input pin delay on the MISO pin is closer to the 20 ns specification your current setup violates.

Regards,

John

Hi zlogic,

Please refer to Table 19.1 in the EFM8LB1 Reference Manual.

I am not sure why this is not in the datasheet, but it provides the SPI timing parameters.  In master mode, the input setup time is 20 ns.

If you are running the SPI at 36 MHz, your clock cycle is 27.7 ns, and the clock half cycle is 13.88 ns. Consequently, the 20 ns input setup time is longer than the clock half cycle, meaning you are violating the input setup time by running the SPI clock at 36 MHz.

This is why master mode operation is specified for a maximum of 12 MHz. You just got lucky that the one device you are using happens to work at 36 MHz. You may have gotten a device that has slightly shorter pin input delays or you may have mapped the SPI to pins that have shorter input delays than other pins on the device.

Regardless, if you were to attempt to produce such a design, we would expect you would have some fallout because you would eventually have some device where the input pin delay on the MISO pin is closer to the 20 ns specification your current setup violates.

Regards,

John

Hi Alain,

Ubuntu 20.10 has the community-developed CP210x driver (cp210x.c). You should not have any need to "install" our driver because it is already there.

Furthermore, udev should recognize the device either when you boot or upon a hot plug event and load the driver for you.

You should not be downloading and otherwise building the driver from our web site. This is provided for customers who need CP210x GPIO support that uses ioctls, which is what we implemented very early in the product's life cycle. Since then, the Linux kernel has migrated from ioctl GPIO support to /dev/gpiochip, and the community-developed CP210x driver supports this.

Regards,

John

Hi AR,

You are good to go.

While we don't yet publish this in the datasheet, the nominal VOA/VOB 1.8V outputs for EFP01 are actually like 1.858V. They include just enough headroom to be above the AVDD BOD threshold you've observed. Once you're up and running, you can goose this up a little bit if you're concerned about it being too close for comfort (or if you need to accommodate loading for anything else powered on such a 1.8V nominal supply rail).

Regards,

John

Hi Hans,

Simple answer here: Don't use that PC!

Is there a chance the port you are connecting to is a USB 3.0 port?

We've run into issues with early implementations of USB 3.0 host support that cause problems not only with our devices but also with similar fixed function devices (e.g. not something running Linux, for example).

In these cases, there is no fix except to not use the PC in question or, if the PC has dedicated USB 2.0 ports that are not backed by a USB XHCI controller, to use the dedicated USB 2.0 ports.

As a case in point, we have some Dell notebook PC docks here from around 2014 - 2015, and these have side-mounted USB 3.0 ports.  Those ports sometimes do not correctly enumerate not only the CP210x but even other USB devices.  The same docks have USB 2.0 ports on the rear, and these ports behave correctly.

Now, why the CP2102N is sending junk on this particular PC I can't really diagnose.  The random nature of the data makes me think that either it has (a) poorly implemented USB VBUS power switching or sourcing that results in a slow ramp on VBUS which is causing the CP2102N to start-up improperly, (b) some kind of damage in the USB subsystem that is causing the same slow ramping, or (c) a substandard USB cable that is interfering with VBUS ramp.

Regardless of the source, I think you're looking at one specific problematic PC.  There could be other factors affecting power delivery, too, e.g. too many devices connected to the root hub drawing too much power and in turn, mucking with what the CP2102N needs to see on VBUS.  We've routinely found that desktop and notebook PCs don't do anything to limit USB power delivery in compliance with the standard.  In other words, pretty much every PC out there will let a device draw more than the 500 mA limit for USB 2.0 and lower devices (900 mA for USB 3.0), and if you have a few devices connected like this, the only thing that might stop it is if the USB power switches in the PC have a fuse that gets blown when too much current is draw (and we hardly ever see this either given how cheap PC vendors are).

Regards,

John

Hi Hans,

Simple answer here: Don't use that PC!

Is there a chance the port you are connecting to is a USB 3.0 port?

We've run into issues with early implementations of USB 3.0 host support that cause problems not only with our devices but also with similar fixed function devices (e.g. not something running Linux, for example).

In these cases, there is no fix except to not use the PC in question or, if the PC has dedicated USB 2.0 ports that are not backed by a USB XHCI controller, to use the dedicated USB 2.0 ports.

To wit: We have some Dell notebook PC docks here from around 2014 - 2015, and these have side-mounted USB 3.0 ports. Those ports sometimes do not correctly enumerate not only the CP210x but even other USB devices. The same docks have USB 2.0 ports on the rear, and these ports behave correctly.

Now, why the CP2102N is sending junk on this particular PC I can't really diagnose. The random nature of the data makes me think that either it has (a) poorly implemented USB VBUS power switching or sourcing that results in a slow ramp on VBUS which is causing the CP2102N to start-up improperly, (b) some kind of damage in the USB subsystem that is causing the same slow ramping, or (c) a substandard USB cable that is interfering with VBUS ramp.

Regardless of the source, I think you're looking at one specific problematic PC.

There could be other factors affecting power delivery, too, e.g. too many devices connected to the root hub drawing too much power and in turn, mucking with what the CP2102N (and other devices) needs to see on VBUS. We've routinely found that desktop and notebook PCs don't do anything to limit USB power delivery in compliance with the standard. In other words, pretty much every PC out there will let a device draw more than the 500 mA limit for USB 2.0 and lower devices (900 mA for USB 3.0), and if you have a few devices connected like this, the only thing that might stop it is if the USB power switches in the PC have a fuse that gets blown/opened when too much current is draw (and we hardly ever see this either given how cheap PC vendors are).

Regards,

John

Hi Hans,

Simple answer here: Don't use that PC!

Is there a chance the port you are connecting to is a USB 3.0 port?

We've run into issues with early implementations of USB 3.0 host support that cause problems not only with our devices but also with similar fixed function devices (e.g. not something running Linux, for example).

In these cases, there is no fix except to not use the PC in question or, if the PC has dedicated USB 2.0 ports that are not backed by a USB XHCI controller, to use the dedicated USB 2.0 ports.

To wit: We have some Dell notebook PC docks here from around 2014 - 2015, and these have side-mounted USB 3.0 ports.  Those ports sometimes do not correctly enumerate not only the CP210x but even other USB devices.  The same docks have USB 2.0 ports on the rear, and these ports behave correctly.

Now, why the CP2102N is sending junk on this particular PC I can't really diagnose.  The random nature of the data makes me think that either it has (a) poorly implemented USB VBUS power switching or sourcing that results in a slow ramp on VBUS which is causing the CP2102N to start-up improperly, (b) some kind of damage in the USB subsystem that is causing the same slow ramping, or (c) a substandard USB cable that is interfering with VBUS ramp.

Regardless of the source, I think you're looking at one specific problematic PC.  There could be other factors affecting power delivery, too, e.g. too many devices connected to the root hub drawing too much power and in turn, mucking with what the CP2102N needs to see on VBUS.  We've routinely found that desktop and notebook PCs don't do anything to limit USB power delivery in compliance with the standard.  In other words, pretty much every PC out there will let a device draw more than the 500 mA limit for USB 2.0 and lower devices (900 mA for USB 3.0), and if you have a few devices connected like this, the only thing that might stop it is if the USB power switches in the PC have a fuse that gets blown when too much current is draw (and we hardly ever see this either given how cheap PC vendors are).

Regards,

John

Hi Hans,

Simple answer here: Don't use that PC!

Is there a chance the port you are connecting to is a USB 3.0 port?

We've run into issues with early implementations of USB 3.0 host support that cause problems not only with our devices but also with similar fixed function devices (e.g. not something running Linux, for example).

In these cases, there is no fix except to not use the PC in question or, if the PC has dedicated USB 2.0 ports that are not backed by a USB XHCI controller, to use the dedicated USB 2.0 ports.

As a case in point, we have some Dell notebook PC docks here from around 2014 - 2015, and these have side-mounted USB 3.0 ports.  Those ports sometimes do not correctly enumerate not only the CP210x but even other USB devices.  The same docks have USB 2.0 ports on the rear, and these ports behave correctly.

Now, why the CP2102N is sending junk on this particular PC I can't really diagnose.  The random nature of the data makes me think that either it has (a) poorly implemented USB VBUS power switching or sourcing that results in a slow ramp on VBUS which is causing the CP2102N to start-up improperly, (b) some kind of damage in the USB subsystem that is causing the same slow ramping, or (c) a substandard USB cable that is interfering with VBUS ramp.

Regardless of the source, I think you're looking at one specific problematic PC.  There could be other factors affecting power delivery, too, e.g. too many devices connected to the root hub drawing too much power and in turn, mucking with what the CP2102N needs to see on VBUS.  We've routinely found that desktop and notebook PCs don't do anything to limit USB power delivery in compliance with the standard.  In other words, pretty much every PC out there will let a device draw more than the 500 mA limit for USB 2.0 and lower devices (900 mA for USB 3.0), and if you have a few devices connected like this, the only thing that might stop it is if the USB power switches in the PC have a fuse that gets blown when too much current is draw (and we hardly ever see this either given how cheap PC vendors are).

Regards,

John

Hi Lionel,

I am not an expert on the .hex format, but I believe you would simply add a new extended linear address record before the EOF line in your .hex file, followed by a new data record, like this:

:020000040001F9
:20EC00004D85A89549E18B8BD5322F8545DC8869237AA18960D6B93762813D3183F0980986
:00000001FF

I pulled this out of a .hex file with random data that I generated for some work on a customer return. The first line sets the new linear base address at 0x10000. The second line consists of 32 bytes of data that start at offset 0xEC00 from the last specified linear base address. I think this would do what you want.

Regards,

John

Hi Lionel,

I am not an expert on the .hex format, but I believe you would simply add a new extended linear address record before the EOF line in your .hex file, followed by a new data record, like this:

:020000040001F9
:20EC00004D85A89549E18B8BD5322F8545DC8869237AA18960D6B93762813D3183F0980986
:00000001FF

I pulled this out of a .hex file with random data that I generated for some work on a customer return. The first line sets the new linear base address at 0x10000. The second line consists of 32 bytes of data that start at offset 0xEC00 from the last specified linear base address. I think this would do what you want.

Regards,

John