Hi Dawson,

Just be be clear, we don't support bare metal host upgrades like you are describing.

It's not that it can't be done, but it would be a sizable effort to implement these across different architectures. This is why, generally speaking, our host code runs on a POSIX-compliant machine (e.g. the NCP and RXP host program we provide for Linux).

As I mentioned above, we've run into substantial headaches trying to support customers who wanted to run a bootloader host on a variety of bare metal devices (none of which were our processors either), and there always seem to be hiccups with proper transmission and reception of the serial data and the particular XMODEM software implementations.

So, this is why I said you'd be pretty much on your own. The AN0003 bootloader, at least, is simple enough that there's not a lot of effort to send the serial commands, but I can't make any promises about how compatible a particular XMODEM implementation you might try to use would be.

Hi Dawson,

if you are trying to have the GG11 do a firmware update for an xG21 using Gecko Bootloader, you're on your own.

We don't support use of a non-PC type host to do USART firmware updates (XMODEM uploads) to Gecko Bootloader.

The trouble is coming up with a reliable XMODEM upload implementation for a bare metal embedded device. We've had other customers try to to do this on a range of embedded devices (not capable of running Linux), and it's been like pulling teeth.

I would suggest you're looking at a lot of pain going this route. Also, if you are planning to use BLE, why not just do OTA firmware updates for the xG21?

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