The clock of the I2C bus is composed of four regions:
Because the I2C module uses pins in open-drain mode, the fall time is relatively negligible, since the drivers will be pulling low reasonably quickly. The other three times compose the overall clock speed.
Low time and High time are set by fields in the SiM3xxxx I2C module: SCLL in I2Cn_SCONFIG for the SCL Low time, and T1RL in I2Cn_TIMERRL for the SCL High time. The third period, Rise time, will be completely dependent upon the hardware (capacitance on the line, pull-up resistor values, etc.). The timers in the I2C hardware do not start counting high and low times until the clock reaches a certain high or low threshold. Therefore, T1RL and SCLL should be adjusted based on the minimum required low time and high time to achieve the overall desired clock rate.
For example, this scope capture uses the SiM3L1xx I2C Master example included with the v1.1.2 SDK. This is the resulting clock and data lines without any pull-ups on the lines, and the rise times are very slow, as expected. The equivalent clock speed is 113 kHz with the values used in the example:
// SETUP MODULE
// set I2C clock to operate at 400 kHZ
This second capture shows the same lines on the same board with the exact same code. The only difference here is the addition of 1 kohm pull-ups on the SDA and SCL pins, which results in a 454 kHz clock.
In other words, SCLL and T1RL can be thought of as the minimum low and high times for the I2C clock. These numbers will need to be adjusted for each hardware platform to achieve the actual desired clock.
The original author of the code example chose the minimum low and high times required to achieve 400 kHz with two boards connected together through external/loose wires.
By default, the I2C module will continue to operate when the core is halted in debug mode. If a breakpoint is set inside the ISR, the state machine triggers the start interrupt, and the SCL low timeout occurs while stepping through the code in the ISR.
To debug the I2C ISR, the module includes a bit called DBGMD in the I2C0_CONTROL register that will put the I2C state machine in a halted state when debugging (i.e. using a breakpoint). However, this bit does not also halt the timers controlling SCL low timeout. The TIMEREN bit in I2C0_CONFIG must also be set to halt this timer. With both DBGMD (SI32_I2C_A_enable_stall_in_debug_mode) and TIMEREN (SI32_I2C_A_enable_all_timers) set, the SCL low timeout will no longer occur while debugging.
There are some side effects with the state machine that can occur when TIMEREN is set while the I2C module is enabled (I2CEN = 1), which is why the Reference Manual recommends not using this configuration. To avoid these situations:
1. Program the Timer Mode (TMD in I2C0_CONFIG) to 0x00 to operate the timer as a 32-bit field.
2. Program SETUP in I2C0_SCONFIG to a non-0xF or non-0x0 value. This will ensure the Timer3 overflow will not occur.
The above is only recommended for situations when debugging the I2C ISR directly. Otherwise, we recommend never setting TIMEREN when I2CEN is set to 1.
Revision 1.0 of the CP2114 data sheet says MCLK is an input in Table 14. However, the description in section 5.3 seems to indicate MCLK is an output. Which is correct?
The CP2110 uses the USB HID driver, which Linux, Mac, and Windows have built-in to the operating system. The implementations of this driver are different for each operating system, and these USB drivers may poll the CP2110 device at different rates.
The CP2110 requests an IN token every frame (e.g. once every millisecond); however, some operating systems often cannot achieve that rate and will instead send an IN token every 2 or 3 frames. Using a USB bus analyzer, the logs should show two or three SOF (Start of Frame) packets between each IN packet, and there will be no IN NAK packets.
It may also be helpful to experiment by plugging into different hubs or USB ports on the same machine. Sometimes a host will poll devices plugged directly into its host controller more often than devices plugged into hubs.
Version v6.6.1 of the VCP driver and v4.0 of the USBXpress driver use a new driver installer software called DPInst. This installer software is created and maintained by Microsoft, and separate installers must be created for a particular OS type (32-bit or 64-bit). It's possible to create an installer wrapper that automatically detects the OS type and appropriately calls the lower-level DPInst installer. More information on this can be found in the linked article.
More information on DPInst can be found here:
The method in which this function is called will vary based on the installation software.
Troubleshooting Basic USB Enumeration Problems
IntroductionIt is very common to have problems that prevent a USB device from successfully enumerating on a PC. These problems can be due to firmware bugs or a configuration problem on the host. We recommend that developers working on USB firmware start with the closest USB example that is known to enumerate and work correctly. Next modify the USB descriptors and device configuration for your target application. It is very easy to break USB enumeration by modifying USB descriptors incorrectly. Fortunately, there are several tools available on Windows that help track down problems with enumeration. As always, refer to the latest USB specification for exact descriptor formats.
Hardware USB Analyzer with PC Software
Perhaps the most useful tool for debugging USB enumeration problems is a good hardware or software USB analyzer. Please see KB311205 for a list of USB analyzers. Most analyzer software will decode USB transfers and point out any warnings or errors during the enumeration process.
The screenshot below shows a USB trace for a successful device enumeration using the Ellisys Visual USB software. As you can see, there is a warning due to a USB reset at the start of the enumeration process and another during the first GetDescriptor request. This warning is normal because on Windows, the host controller asks for the first 8 bytes of the device descriptor and then sends a request for the full device descriptor. An easy way to know that the device has finished enumerating correctly is to look for the SetConfiguration(1) request. This is the last step that the host controller performs before the PC host driver can open pipes to the device.
Ellisys Visual USB - Successful Enumeration
In the next screenshot, you will see another USB trace where the USB device descriptor length is invalid in the firmware. In this case, the length field is set to 16, when it should be 18 bytes. Notice how the analyzer software marks the GetDescriptor(Device) request with a warning and indicates that the bLength field is invalid. The PC USB host controller tries four times to enumerate the device, but ends up failing and aborts the enumeration process.
Ellisys Visual USB - Invalid Descriptor Length
USB Device Viewer
Another useful tool that can help debug USB enumeration problems is a free program from Microsoft called USB Device Viewer. This software can be downloaded as a part of the Windows WDK (previously DDK). This software is very useful for viewing USB descriptors and for debugging minor enumeration problems.
The screenshot below displays USB descriptors and information for devices plugged into a Windows machine. Note that the 'Silicon Labs WinUSB Interrupt Device' has enumerated successfully and all descriptors are displayed in the right hand side. We know that the device has enumerated successfully because there are open pipes. In this case, there are two. This means that a driver has been loaded for the device and it has opened two USB pipes successfully.
USB Device Viewer - Successful Enumeration
The next screenshot shows the same problem exhibited in the section above. The device descriptor length field is set to an invalid value of 16 instead of 18 bytes. Notice that USB Device Viewer has decoded the USB descriptors and has reported several errors. The first indicates that there are no open pipes. This means that the device either failed enumeration, or there is no driver loaded for the device. The next error describes the source of the enumeration problem, the device descriptor bLength field is incorrect! Finally the last error indicates that device enumeration has failed.
USB Device Viewer - Invalid Descriptor Length
Enumeration Problems Due to a Bad Configuration on the Host
Another common source of problems isn't actually an enumeration problem at all. During the course of USB firmware development, developers will change USB descriptors and fields such as Vendor ID/Product ID. After several attempts to enumerate the same USB hardware with different descriptors, many times Windows will make some assumptions about the device that are wrong. For every device that enumerates, there is a corresponding registry key entry that contains the VID, PID, serial string, and information about the device. In order to clear out incorrect information about a USB device, it's sometimes necessary to delete the registry key altogether. There are two main methods to delete this key, using the registry editor and using USBDeview.
Deleting USB Device Registry Keys:
The most straightforward method to delete a USB device registry key is to use the built in Registry Editor tool provided by Microsoft. Windows stores USB device information under the following key:
HKLM\CurrentControlSet\Enum\USB\VID_vvvv&PID_ppppsssssss, where vvvv is the vendor ID in hexadecimal, pppp is the product ID in hexadecimal, and sssssss is the serial string (or unique string provided by Windows if the device doesn't have a serial string descriptor).
HID registry keys are located in:
Note that newer versions of Windows don't allow users to delete these registry keys. It may be necessary to run redgedit.exe from another software tool that grants elevated access to the registry. For example, users can run the following command from the command line to run regedit using the System account:
psexec -i -d -s c:\windows\regedit.exe
PsExec is a part of PSTools available from Microsoft at:
Uninstalling USB Devices using USBDeview
USBDeview is a useful software tool that displays all currently connected USB devices as well as any devices that were previously connected.
USBDeview can be used to remove registry keys for old USB devices. Filter the device list by Vendor ID, find the old device entry, right click on the device, and select 'Uninstall Selected Devices' to remove the registry keys for the selected devices.
USBDeview - Uninstall Device
What steps should I take to verify and choose my CODEC/DAC for the CP2114?
When choosing a CODEC examine the CODEC and CP2114 datasheet for possible incompatibilities. Areas to examine include the following:
1. Format and timing specs for digital audio interface signals (MCLK,LRCK,SCK,SDIN,SDOUT)
2. Format, protocol, and timing specs for I2C interface signals (SCL, SDA)
3. The mechanism for controlling CODEC Mute and Volume
The next steps would be to connect the DAC/CODEC evaluation board to the CP2114 motherboard. Note that the CP2114 motherboard has numerous pin headers for this purpose.
Then develop the appropriate CP2114 configuration file(s) based on information in the CODEC datasheet and specific requirements of the application. Then testing will verify the functionality, proper audio performance and conformance with CODEC/CP2114 datasheet specs.
Deleting Windows Registry Keys After Changing CP2114 Configuration
Windows often fails to recognize changes in the CP2114 configuration parameters unless the device driver is uninstalled and reinstalled. Old registry keys can also cause problems and should be removed when changing the CP2114 configuration.
Beginning with Windows7, a user cannot delete USB device keys using RegEdit, even if it’s run in Administrator mode. The USBDeview utility allows you to easily uninstall USB devices and remove all keys from the registry. To uninstall the CP2114 using USBDeview:
USBDeview.exe /remove_by_pid /showmsg 10C4;EAB0 echo Exit code: %errorlevel%Note: If the location of USBDeview.exe is not in the system path, the complete path must be specified. If the path contains spaces, the path and filename must be enclosed in quotes, e.g.:
"C:\Program Files\USBDeview64\USBDeview.exe" /remove_by_pid /showmsg 10C4;EAB0
If you wish to modify any of the GPIO settings for the unused (non-EZSP) pins of the EM35x NCP, you can make use of the following EZSP commands (described here via the comments of the provided host API driver code from app/util/ezsp/command-prototypes.h):
// Sets the GPIO configuration and output values for the specified pin. // Return: EZSP_SUCCESS if the values were changed, EZSP_ERROR_INVALID_VALUE if // the pin was out of bounds, EZSP_ERROR_INVALID_CALL if the pin could not be // modified because it is required for communication with the NCP. EzspStatus ezspSetGpioCurrentConfiguration( // The pin to configure. int8u portPin, // The new configuration value. int8u cfg, // The new output value. int8u out); // Sets the GPIO configuration and output values to be used for the specified // pin when the NCP is powered up and down. // Return: EZSP_SUCCESS if the values were changed, EZSP_ERROR_INVALID_VALUE if // the pin was out of bounds, EZSP_ERROR_INVALID_CALL if the pin could not be // modified because it is required for communication with the NCP. EzspStatus ezspSetGpioPowerUpDownConfiguration( // The pin to configure. int8u portPin, // The new configuration value for power up. int8u puCfg, // The new output value for power up. int8u puOut, // The new configuration value for power down. int8u pdCfg, // The new output value for power down. int8u pdOut); // Sets the mask that controls which pins will have their GPIO configuration and // output values set to their power-up and power-down values when the NCP powers // the radio up and down. void ezspSetGpioRadioPowerMask( // The new mask. int32u mask);
Note that ezspSetGpioRadioPowerMask() should be used to control any front-end module (FEM) or external LNA/PA signals that require specific configurations to facilitate RF communication. For designs that require Radio Holdoff support (as input to pin PA6), activation of the Radio Holdoff feature should be done through a call to ezspSetValue(EZSP_VALUE_RADIO_HOLD_OFF, TRUE), rather than using of one of the above GPIO-related ezspXXX host API calls:
...The parameters for the above ezspSetGpioXXX functions should be interpreted as follows:
'portPin' represents the GPIO to manipulate. These are enumerated 0-23 to correspond to the 24 GPIOs, with the first 8 values representing PA0 - PA7, the next 8 values representing PB0 - PB7, and the final 8 values (16-23) representing PC0 - PC7. Refer to the following list of pins, default functions and portPin numbers below for guidance:
EM35x Pin | Default Function | Port/pin # | Decimal equivalent
PA0 SC2MOSI 0 0
PA1 SC2MISO 1 1
PA2 SC2SCLK 2 2
PA3 SC2nSSEL 3 3
PA4 PTI_EN 4 4
PA5 PTI_DATA 5 5
PA6 LED0 6 6
PA7 LED1 7 7
PB0 Power Amplifier Shutdown Control 8 8
PB1 SC1TXD 9 9
PB2 SC1RXD A 10
PB3 SC1nCTS B 11
PB4 SC1nRTS C 12
PB5 TEMP_SENSE D 13
PB6 Button0 E 14
PB7 Buzzer F 15
PC0 JTAG (JRST) 10 16
PC1 Power Amplifier antenna select control 11 17
PC2 JTAG (JTDO) 12 18
PC3 JTAG (JTDI) 13 19
PC4 JTAG (JTMS) 14 20
PC5 LED2/TX-ACTIVE 15 21
PC6 Button1/nTX-ACTIVE 16 22
PC7 TEMP_EN 17 23
'cfg' represents the GPIO_PxCFGL/H register setting for Port x (A/B/C) that you want to effect on the target GPIO pin. Refer to Table 7.1 of the EM35x Datasheet for details about the valid values for this field.
'out' represents the GPIO_PxOUT register setting for Port x (A/B/C) that you want to effect on the target GPIO pin. Valid values are 0 or 1, where 0 represents output low (if pin is configured as an output) or pulled-up input (if pin is configures as an input with pullup/down enabled), and 1 represents output high or pulled-down input.
What are the differences between the Windows WLK and HCK driver recertification process?
Windows WLK (Windows Logo Kit) refers the certification process prior to the release of Windows 8. Customized Silicon Labs VCP drivers prior to v6.0 use this process.
Windows HCK (Hardware Certification Kit) refers the certification process used by Microsoft since the release of Windows 8. Customized Silicon Labs VCP drivers v6.0 and later use this process.
The procedures for the WLK and HCK driver recertification process are attached.
AN809: Integrating the CP210x Virtual COM Port Driver into the Android Platform describes how to add support for CP210x to an Android platform. Application Notes can be found on www.silabs.com/interface-appnotes.
Despite enabling dynamic suspend and configuring the suspend latch to logic low in the CP210xPortConfig application, the CP2104 TX pin will not go logic low during suspend.
To set the TX pin low during suspend:
1. Call SetCommBreak() before entering suspend from the application. SetCommBreak() is a windows API function that is documented here:
Leaving suspend, the customer's application should call ClearCommBreak():
Limitation: recommendation #1 requires the application to have an open handle to the CP2104. This is by definition of the function. SetCommBreak() and ClearCommBreak() can not be called without passing an open handle as a parameter.
2. Use the CP2103. Enabling dynamic suspend and configuring the suspend latch to logic low in the CP210xPortConfig application will cause the CP2103 TX pin to go logic low during suspend.
Application Note software AN220SW can generate customized VCP drivers (v6.6 and later) and USBXpres drivers (v3.3 and later) with a silent or GUI installer using Microsoft's DPInst installer. Once a silent driver installer is generated, it is not necessary to use the Application Note software AN220SW to obtain a GUI version of the installer.
To change a silent installer to a GUI installer, remove the <quietInstall/> XML element from the dpinst.xml file.
To change a GUI installer to a silent installer, add the <quietInstall/> XML element to the dpinst.xml file.
The quietInstall configuration flag can also be enabled via command line.
An unsigned, customized VCP driver v6.6 (or later) or USBXpress driver v3.3 (or later) driver with silent installer is expected to fail installation.
When a user attempts to install an unsigned driver, the user will recieve a prompt warning stating the driver is unsigned. The user must accept this warning for the installation to succeed.
With a silent installer, the warning prompt is suppressed, the user will not be able to accept the warning, and thus the installation will fail.
To install an customized driver, either:
- Use the GUI installer instead of the silent installer. See the 'How can I switch between a silent and GUI driver installer?' article in the related articles section.
- Recertify/sign the driver. See the 'WHQL Testing' article in the related articles section.