What is the right way to determine the revision (A01/A02/...) of my CP2615?
In Section 3.6.2.3 "Special Operations", the CP2615 Datasheet depicts (in Table 3.13 "Read CP2615 Firmware Revision") an operation available in Configuration Mode to read the Firmware Version Number.
In Section 3.2 "iop_AccessoryInfo", AN1139: CP2615 I/O Protocol depicts a "PartID" described as "Encoded part number of the chip (0x1400 for CP2615-A01, 0x1500 for CP2615-A02)."
Answer:
Reading the version via I2C in config mode requires an external I2C Master, e.g. the special-PID CP2112 on the CP2615 EVB. This method is suitable for a prototyping environment (it's how Xpress Configurator determines the attached device), or in a customer's production-line environment (e.g. the external I2C master can verify the proper device version before programming the config). For this method, the CP2615 must be powered up, but doesn't have to be connected to a USB host. See Knowledge Base Article "Parsing the CP2615 Firmware Version Number" for details on how to interpret this value.
Reading the version via the iop protocol is suitable for an end-user situation, e.g. an app running on the phone or USB host would query the version number before issuing any version-dependent commands (e.g. downloading user profiles, which is only supported on the -A02).
When being programmed with a new configuration, the CP2114-B01 and CP2114-B02 devices can sometimes write corrupted configuration data when SYSCLK is currently being driven by the internal 49.152 MHz oscillator and the size of the new configuration data block is greater than 62 bytes.
The problem does not occur in other SYSCLK modes. To prevent the possibility of corruption when programming a new configuration, the CP2114 should be operating in one of these three SYSCLK modes:
SYSCLK is driven by the internal oscillator at 48 MHz (e.g. factory-programmed config[0]).
SYSCLK is driven by an external oscillator at 48 MHz.
SYSCLK is driven by an external oscillator at 49.152 MHz.
WHQL Certified drivers are selected over non-certified drivers, and higher version numbers are selected over lower version numbers. Installing a newer driver will not uninstall an older version, but the older version will no longer be used.
How can I achieve the Datasheet sleep current numbers for CPT007B, CPT112S and CPT212B using the Eval Boards?
Sleep Current Values
Device Name (all sensors)
Current (uA)
CPT007B
0.84
CPT112S
0.95
CPT212B
0.95
Note - CPT213B does not go into sleep mode to avoid violating the IEC-60730 safety specs.
Answer
The average current drawn is going to be a function (mainly) of the sleep mode scan time (~250 us) and to some extent the sensors included as wake up sources. Scan can take more time if there are more sensors. If all sensors are designated as wake up sources and drive strength is set to 8x, the typ sleep current value shown in the Datasheet can be reflected in an eval board. However, if an eval board is tested for current consumption numbers, one may see a sleep current of the order of a few mA. This is because there are a few additional items to keep in mind -
Buzzer circuit
The buzzer circuitry on the CPT boards does not allow it to go to sleep mode. On energy profiler, one will not seeing the sleep scan happen every 250 ms and the current will be of the order of 3 mA. If the buzzer is enabled in the profile but the pin configuration is set to open drain, the current will be of the order of 3.5 uA. Even when the buzzer was disabled the average current stayed at 3-4 uA. If the buzzer's pin configuration is not programmed at all, it defaults to push-pull and if the buzzer circuitry is connected, it will draw more current and not allow the part to go into sleep mode. So the solution is to remove the buzzer from the board, i.e., the transistor and resistors around it. Here is a screenshot from the eval board schematic -
Device Revision in CPT007B and CPT112S
Despite the change made in #1. shown above, some CPT007B and CPT112S boards might still show a current of about 3 uA. This is a known issue. The attached errata throws more light about this issue. The rev A02 of CPT007B and CPT112S shows the correct current numbers.
There is a bug in the CP2114 Customization Utility that does not preserve changes made by the user in the DAC Configuration window. Example of unexpected behavior below.
1. Connect a CP2114 (B01 or B02) in a PC and open the CP21xxCustomizationUtility.exe
2. Navigate to the DAC Configuration. Read first empty index (3 in this case). Note that DacConfig in this example is currently 00.
3. Make a change to DacConfig, eg 00 to 11. Close window.
4. Unexpectedly, DacConfig is not 11.
Workaround
To edit the DAC configuration:
In the CP2114 Customization Utility, save the configuration to a file using the "Save to file" button.
Open the exported file in a text editor.
Edit the DAC configuration. Your DAC configuration should be located after the "#DAC config" comment in the file.
01 # [44] PbTerminalTypeLsb
03 # [45] PbTerminalTypeMsb
02 # [46] RecTerminalTypeLsb
06 # [47] RecTerminalTypeMsb
00 # [48] Reserved1
00 # [49] Reserved2
# DAC config
F9
6E
00
47
04
64
FA
64
o
o
o
Interface Knowledge Base
Methods to determine CP2615 revision
Question:
What is the right way to determine the revision (A01/A02/...) of my CP2615?
In Section 3.6.2.3 "Special Operations", the CP2615 Datasheet depicts (in Table 3.13 "Read CP2615 Firmware Revision") an operation available in Configuration Mode to read the Firmware Version Number.
In Section 3.2 "iop_AccessoryInfo", AN1139: CP2615 I/O Protocol depicts a "PartID" described as "Encoded part number of the chip (0x1400 for CP2615-A01, 0x1500 for CP2615-A02)."
Answer:
Reading the version via I2C in config mode requires an external I2C Master, e.g. the special-PID CP2112 on the CP2615 EVB. This method is suitable for a prototyping environment (it's how Xpress Configurator determines the attached device), or in a customer's production-line environment (e.g. the external I2C master can verify the proper device version before programming the config). For this method, the CP2615 must be powered up, but doesn't have to be connected to a USB host. See Knowledge Base Article "Parsing the CP2615 Firmware Version Number" for details on how to interpret this value.
Reading the version via the iop protocol is suitable for an end-user situation, e.g. an app running on the phone or USB host would query the version number before issuing any version-dependent commands (e.g. downloading user profiles, which is only supported on the -A02).
CP2114 fails to program config when SYSCLK is internal 49.152 MHz oscillator
When being programmed with a new configuration, the CP2114-B01 and CP2114-B02 devices can sometimes write corrupted configuration data when SYSCLK is currently being driven by the internal 49.152 MHz oscillator and the size of the new configuration data block is greater than 62 bytes.
The problem does not occur in other SYSCLK modes. To prevent the possibility of corruption when programming a new configuration, the CP2114 should be operating in one of these three SYSCLK modes:
How does Windows select between multiple versions of a driver for a particular device
WHQL Certified drivers are selected over non-certified drivers, and higher version numbers are selected over lower version numbers. Installing a newer driver will not uninstall an older version, but the older version will no longer be used.
For more information, see this knowledge base article from Microsoft: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/how-setup-ranks-drivers--windows-vista-and-later-
ERROR: syntax: invalid hex number size
What does it mean when cp210xsmt.exe tool produces the message "ERROR: syntax: invalid hex number size with CP210x .configuration file"?
One of the text fields in the configuration file is longer than expected, for example:
Instead of:
Sleep Current in CPT Devices
Question
How can I achieve the Datasheet sleep current numbers for CPT007B, CPT112S and CPT212B using the Eval Boards?
Note - CPT213B does not go into sleep mode to avoid violating the IEC-60730 safety specs.
Answer
The average current drawn is going to be a function (mainly) of the sleep mode scan time (~250 us) and to some extent the sensors included as wake up sources. Scan can take more time if there are more sensors. If all sensors are designated as wake up sources and drive strength is set to 8x, the typ sleep current value shown in the Datasheet can be reflected in an eval board. However, if an eval board is tested for current consumption numbers, one may see a sleep current of the order of a few mA. This is because there are a few additional items to keep in mind -
The buzzer circuitry on the CPT boards does not allow it to go to sleep mode. On energy profiler, one will not seeing the sleep scan happen every 250 ms and the current will be of the order of 3 mA. If the buzzer is enabled in the profile but the pin configuration is set to open drain, the current will be of the order of 3.5 uA. Even when the buzzer was disabled the average current stayed at 3-4 uA. If the buzzer's pin configuration is not programmed at all, it defaults to push-pull and if the buzzer circuitry is connected, it will draw more current and not allow the part to go into sleep mode. So the solution is to remove the buzzer from the board, i.e., the transistor and resistors around it. Here is a screenshot from the eval board schematic -
Despite the change made in #1. shown above, some CPT007B and CPT112S boards might still show a current of about 3 uA. This is a known issue. The attached errata throws more light about this issue. The rev A02 of CPT007B and CPT112S shows the correct current numbers.
CP2114 Customization Utility - DAC configuration bug and workaround
Problem
There is a bug in the CP2114 Customization Utility that does not preserve changes made by the user in the DAC Configuration window. Example of unexpected behavior below.
1. Connect a CP2114 (B01 or B02) in a PC and open the CP21xxCustomizationUtility.exe
2. Navigate to the DAC Configuration. Read first empty index (3 in this case). Note that DacConfig in this example is currently 00.
3. Make a change to DacConfig, eg 00 to 11. Close window.
4. Unexpectedly, DacConfig is not 11.
Workaround
To edit the DAC configuration: