When using the CP240x LCD controller for a battery powered application where lowest power operation is the goal, what is the best device configuration and pin interfacing options to use? Specifically:
1) Is it sufficient to use either 20 kHz or 40kHz self-oscillate mode (i.e. without a crystal or external clock) for clocking the LCD controller and I2C communications functions?
2) During I2C communications, is it necessary to switch to the 20MHz (divided by n) Internal oscillator? 3) Does this potential clock switch happen in automatic way or does it need the use of the “/PWR” input? 4) If the “/PWR” pin should not be used, is it preferred connecting it to GND or VDD? 5) Shall the unused “/CLK” pin be connected preferentially to GND or VDD? 6) Can the unused “XTAL1” (input) be connected to GND or VDD? 7) Can the unused “XTAL2” (output) be connected to GND or VDD or has to be left floating? 8) Is it advised connecting the unused “/INT” pin to GND or is it better leave it floating? 9) Shall the metal pad (thermal pad) at the bottom of the component be connected to GND (externally) or has to be left floating?
Answer
When using the CP240x devices in low power applications, please note that there is a known issue where sometimes when re-entering sleep mode (after a wake-up) the part does not fully go into shutdown. The partial sleep state is generally in the 1.3 uA range, though it can vary. This issue never occurs when entering sleep for the first time after a reset.
There is an errata being put in place for this issue.
We have a partial work around which is to reset the MCU before entering sleep mode. This will ensure that sleep mode is entered properly, but it does incur some extra power consumption since the device consumes higher than average current for a brief time when coming out of reset. If the part is going to be asleep for only a brief period then the reset may waste more power then it saves.
An additional workaround for systems in development would be to power the CP240x from an extrnal MCU and completely remove the supply to the device instead of putting it in sleep mode. Please note that if this is the case, the CP240x will need to be reconfigured after each power on, and LCD control will be unavailable in the OFF mode.
1) Is it sufficient to use either 20 kHz or 40kHz self-oscillate mode (i.e. without a crystal or external clock) for clocking the LCD controller and I2C communications functions?
The 20 kHz or 40 kHz self-oscillate mode of the SmaRTClock is sufficient for standard LCD controller functionality. This functionality is available in Normal mode (see sec 9.1, p.50 of the CP240x datasheet) as well as Ultra Low Power (ULP) LCD mode (see section 9.3, p. 51). Transitions into and out of this ULP LCD and other ULP/Shutdown modes are handled using different combinations of control register settings and rising/falling edges on the /PWR pin (please consider the errata condition mentioned above when deciding on how to utilize low power modes vs, device power off). I2C communications are available between the host MCU and the CP240x only in Normal mode, when the internal 20 MHz oscillator (which is separate from the SmaRTClock oscillator) is active.
2) During I2C communications, is it necessary to switch to the 20MHz (divided by n) Internal oscillator?
I2C communications are available between the host MCU and the CP2403 only in Normal mode, when the internal 20 MHz oscillator (which is separate from the SmaRTClock oscillator) is active. Data can be transferred by the SMBus/I2C at up to 1/20 of the system clock, or the maximum speed allowed by the SMBus specification, whichever is slower.
3) Does this potential clock switch happen in automatic way or does it need the use of the “/PWR” input?
If you are going to use ULP LCD mode, the device will continue to use the SmaRTClock (RTC) timebase to enable LCD control. After wakeup from any of the ULP modes, firmware must reconfigure any registers that do not retain their state in ULP modes, including the CLKSEL register (clock select) and IOSCCN register (internal oscillator control). Follow the instructions on page 50-53 for procedures to enter and exit ULP modes using the /PWR pin (as well as consider the errata condition mentioned above).
4) If the “/PWR” pin should not be used, is it preferred connecting it to GND or VDD?
Entry into ULP modes is triggered by a rising edge transition on the /PWR pin. If unused, this pin can be driven to GND or VDD.
5) Shall the unused “/CLK” pin be connected preferentially to GND or VDD?
The lowest power option for the /CLK pin is to tie it to VDD.
6) Can the unused “XTAL1” (input) be connected to GND or VDD?
You can leave the unused XTAL1 pin floating.
7) Can the unused “XTAL2” (output) be connected to GND or VDD or has to be left floating?
You can leave the unused XTAL2 pin floating.
8) Is it advised connecting the unused “/INT” pin to GND or is it better leave it floating?
You can leave the unused /INT pin floating.
9) Shall the metal pad (thermal pad) at the bottom of the component be connected to GND (externally) or has to be left floating?
Connect the metal pad on the back of the device to GND.
The default, unmodified drivers from this site are associate with the VID and PID programmed onto CP210x devices by default. These defaults are listed below:
Device
Default VID
Default PID
CP2101-4/CP2102N
0x10C4
0xEA60
CP2105
0x10C4
0xEA70
CP2108
0x10C4
0xEA71
When attaching a CP210x device, it will be necessary to install drivers associated with the device's VID/PID combination before the device will be properly recognized. In most cases, this involves either downloading and manually installing the default driver, or a driver that has been modified by using the utility found with AN200, here: https://www.silabs.com/support/resources.ct-application-notes.ct-example-code.p-interface
However, it is also possible to automatically download install these drivers using Windows Update. Doing this requires a different set of PIDs to be programmed onto the CP210x devices. This allows a user to merely connect a CP210x device to a Windows machine and be able to use it without having to manually download install drivers. The PIDs that must be programmed to the CP210x device are listed below:
I am using a CP2108 in my application, but I've chosen not to implement handshaking. What should I do with the unused handshake pins (RI/DCD/DSR/CTS/RTS/DTR)?
Answer
If you are certain you'll not need to support any handshaking, you can manage these unused pins in your system by:
* Do not use Flow Control * Leave the handshake lines FLOATING
This should provide a robust system configuration for the CP2108 when handshaking capability is not used.
How do I determine CP2105 COM Port Numbers in Windows?
Answer
Once the device has enumerated, Windows will assign the CP2105 two COM port numbers. Here are a couple of ways to look for the COM port numbers.
Manual Method — You can manually check for device enumeration in the Windows Device Manager. The CP2105 will show up as two COM port numbers like below. Note: If you are using a customized driver, the device may not be listed as "Silicon Labs Dual CP210x...", but it will still have COM port numbers.
Programmatic Method — Windows stores the COM port numbers in the Windows registry. Software can be written to search the registry for these COM port numbers. See Application Note AN197 section 7 for details.
Can the CP2114-B02 be operated simultaneously in 24-bit playback mode with 16-bit record, or 24-bit record with 16-bit playback?
Answer
No, when using 24 bit mode with the CP2114-B02, data transfer is uni-directional. Thus you can operate the device in 24-bit record ONLY or 24-bit playback ONLY, but data of any size can not be transferred in the opposite direction. The device can, however, operate in simultaneous 16-bit record/16-bit playback mode.
For more information on the operating modes of the CP2114-B02, the differences between the CP2114-B01 and the CP2114-B02, and information on configuring and customizing the device, please see the CP2114 datasheet:
While operating the CP2114, can I switch between audio configurations on-the-fly? For instance, if operating the CP2114-B02 in 24-bit playback or record mode, can I dynamically switch the device to operate in 16-bit playback/16-bit record mode, or from 24-bit playback to 24-bit record? Other configuration changes could include:
- switching between left-justified and I2S data formats
- changing DAC/CODEC I2C addresses
Are these kind of dynamic configuration changes possible or recommended?
Answer
Because audio configurations for the CP2114 are pre-programmed into the one time programmable (OTP) ROM on the device and loaded at startup, runtime configuration changes are not supported. Although multiple configuration profiles can be programmed into a single device and it is possible to select which among the programmed configurations is loaded at device startup, it is not recommended to run different configurations or switch between configurations in an application.
On-the-fly device configuration switching is not recommended because the enumeration procedure and host behavior make it very likely that changing the device configuration after a device has enumerated for the first time will result in unpredictable and negative behavior. The first time a CP2114 device with a unique serial number enumerates, the host operating system caches some of the device descriptor information associated with that particular device for ease of use when the device disconnects and subsequently reconnects. Thus, if the device disconnects, changes its configuration options,and then re-enumerates, host side processes may access old or stale information from the descriptor cache, resulting in undesired behavior.
The intended purpose of the DAC select pins and the ability to program multiple configurations to the OTP ROM on the device is to enable flexibility for development purposes. Use of these features is not advised for dynamic configurations at run time.
For more information about programming the CP2114, please reference the CP2114 datasheet and AN721:
What is the tHIGH and tLOW period for the CP2112 SMBus?
Answer
The clock high period (tHIGH) is typically twice as large as the clock low period (tLOW) for the CP2112. The duty cycle of this signal is not adjustable
The CP2112's SMBus I/O interface is a two-wire, bi-directional serial bus. The SMBus is compliant with the System Management Bus Specification, version 1.1, and compatible with the I2C serial bus.
Can the CP2114-B01 be distinguished from CP2114-B02 by the package marking?
Answer
No, CP2114-B01 and -B02 can not be distinguished by package marking.
However, the following three device-specific version numbers can be used to distinguish between CP2114-B01 and CP2114-B02 devices:
Name
CP2114-B01
CP2114-B02
API Version
0x05
0x06
Firmware Version
0x07
0x08
Config Version
0x01
0x02
There are four ways to obtain the version numbers that can be used to distinguish between CP2114–B01 and CP2114–B02 devices:
The CP21xx Customization Utility displays the Firmware Version in the device string (CP2114-B02 shown):
The HidUart Example application displays the API Version (CP2114-B02 shown):
The HID-to-UART interface library provides the CP2114_GetVersions function, which returns all three version numbers. For more information, see AN433: CP2110/4 HID-to-UART API Specification.
If not using the HID-to-UART interface library, the Get Device Version report (ID 0x77) can be used to obtain all three version numbers. For more information see AN434: CP2110/4 Interface Specification.
Can the CP2114-B01 be distinguished from CP2114-B02 by the package marking?
Answer
No, CP2114-B01 and -B02 can not be distinguished by package marking.
However, the following three device-specific version numbers can be used to distinguish between CP2114-B01 and CP2114-B02 devices:
Name
CP2114-B01
CP2114-B02
API Version
0x05
0x06
Firmware Version
0x07
0x08
Config Version
0x01
0x02
There are four ways to obtain the version numbers that can be used to distinguish between CP2114–B01 and CP2114–B02 devices:
The CP21xx Customization Utility displays the Firmware Version in the device string (CP2114-B02 shown):
The HidUart Example application displays the API Version (CP2114-B02 shown):
The HID-to-UART interface library provides the CP2114_GetVersions function, which returns all three version numbers. For more information, see AN433: CP2110/4 HID-to-UART API Specification.
If not using the HID-to-UART interface library, the Get Device Version report (ID 0x77) can be used to obtain all three version numbers. For more information see AN434: CP2110/4 Interface Specification.
When issuing a command to the CP2120, the read data is corrupted. What can cause this issue?
Answer
The CP2120 relies on chip select being asserted during the entire command write and response read process. Toggling chip select between this write and read will corrupt the internal state machine and return invalid data.
Make sure that chip select is asserted for the entire duration of each SPI command (including SPI write and SPI read transfer).
The CP2120 has logic to switch the MISO output pin between push pull and open drain mode. The device only drives the MISO pin in push pull mode when it's expected to return data to the SPI master. If the SPI master toggles CS more than once during a SPI command write and then read, the device state machine will enter an invalid state and send bytes with the pin configured as open-drain, which is not a strong enough driver to meet the minimum rise time for high SPI clock rates, resulting in corrupted data being sent to the SPI master.
Interface Knowledge Base
CP240x configuration and pin interfacing for low power applications
Downloading CP210x drivers from Windows Update
Unused handshake pins on the CP2108
Identifying CP2105 COM Port Numbers in Windows
CP2114-B02 24-bit record/playback vs. 16-bit record/playback
CP2114: Switching Configurations on-the-fly
CP2112 SMBus Clock Period
Question
What is the tHIGH and tLOW period for the CP2112 SMBus?
Answer
The clock high period (tHIGH) is typically twice as large as the clock low period (tLOW) for the CP2112. The duty cycle of this signal is not adjustable
The CP2112's SMBus I/O interface is a two-wire, bi-directional serial bus. The SMBus is compliant with the System Management Bus Specification, version 1.1, and compatible with the I2C serial bus.
CP2114 B01 vs B02 Package Marking
CP2114 B01 vs B02 Package Marking
CP2120 SPI command/response is corrupted when toggling CS between SPI write and SPI read