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.

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.

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.

http://www.silabs.com/support/resources.ct-application-notes.ct-example-code.p-interface

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:

http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2114-DataSheet.pdf

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:

http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2114-DataSheet.pdf

http://www.silabs.com/Support%20Documents/TechnicalDocs/AN721.pdf

http://www.silabs.com/Support%20Documents/Software/an721sw.zip

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:

There are four ways to obtain the version numbers that can be used to distinguish between CP2114–B01 and CP2114–B02 devices:

1. The CP21xx Customization Utility displays the Firmware Version in the device string (CP2114-B02 shown):
   
   
   
   
2. The HidUart Example application displays the API Version (CP2114-B02 shown):
   
   
   
   
3. 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.
   
   
4. 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.

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:

There are four ways to obtain the version numbers that can be used to distinguish between CP2114–B01 and CP2114–B02 devices:

1. The CP21xx Customization Utility displays the Firmware Version in the device string (CP2114-B02 shown):
   
   
   
   
2. The HidUart Example application displays the API Version (CP2114-B02 shown):
   
   
   
   
3. 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.
   
   
4. 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.

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.