Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
RevisionDescriptionDate1.0I2C Description10/27/14The I2C topics seem to be a bit confusing.I am creating this Blog to address these concerns.I will po...
The I2C topics seem to be a bit confusing.
I am creating this Blog to address these concerns.
I will post a video shortly that will thru a Code Walk Thru.
There is a known issue with i2cm_* functions.
You must use cfa_* functions instead.
i2cm_* can only be used when patch enable_spiff1_i2c_interop.a is used *and* NV is serial flash on SPI1
Here are miscellaneous notes that have collected regarding the I2C Issues:
Both SCL and SDA should be high before I2C communication begins.
SPIFFY1 is shared with I2C, which is already being used to talk to the EEPROM on the module.
SPI-flash and I2C interfaces concurrent:
We don’t have the drive strength once to drive the I2C line hard enough with a total of 4 slaves on the bus.
How the SDA pin is sampled during boot by the firmware and how the I2C pins behave:
Connecting SDA to Vdd/Vio to recover is probably a bad idea
SCL and SDA are both open-drain
The pull-ups pull the signal high while the HW drives it low
It never drives high, but floats the output pad leaving the pull-up to pull the line high
If you put a scope to either of these lines on the board when the FW accesses these, high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC
If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND - Not good
This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip
Shorting to GND on the other hand, is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line
How to decrease the clock speed during programming (and for subsequent accesses to the EEPROM), because the faster clock speed seems to be causing another i2c device to lock up:
See i2cm.h, i2cm_setSpeed(). Use I2CM_SPEED_* from this header.
If you use cfa_* API that is used by the i2c_temperature_sensor sample, you cannot change the I2C bus speed (defaults to 400KHz). You can use the corresponding API in i2cm.h to read/write the same data and also change speed if required
I2C and P_UART Dependency:
PUART and I2C don't have any dependency. You can use both at the same time. SPI2 and PUART however do have some restrictions, see the datasheet or the HW interfaces document (in short - PUART RX and SI2 have to be on the same GPO bank).
I2C and SPI1 share GPIOs. With SDK 2.1 and above, there is an optional patch with which you can use I2C when SPI1 is used for NV storage (serial flash). But the other way where you want to use SPI1 as an SPI master when using I2C EPROM slave is not possible.
To use it, you just have to include the patch and use the API in i2cm.h:
If you are having problems with your installer, check that the download size of the installer is roughly 260MB, installer problems are typically caused by incomplete downloads.
The picture below shows a very common error message. Our SDK utilizes a 32-bit version of an Eclipse based IDE which requires a 32-bit version of JRE to be installed. If you already have the 64-bit JRE installed, you will also need to install the 32-bit version as well. The JRE is designed to allow both 32 and 64 bit variants to be installed on the system.
The WICED Sense kit uses a Silicon Labs USB to Serial Device. The TAG3 board uses an FTDI USB to Serial Device. Both should be installed as part of the SDK 2.2.1 installation process. If not, the FTDI drivers for the TAG3 reinstall them using the file /WICED-Smart-SDK/Drivers/dpinst.exe (make sure you access from the command line). The Silicon Labs USB Drivers can be foundWICED Sense Table of Contents
Everything we have for the WICED Sense, such as schematics, drivers, and Android application source code, can be accessed through theWICED Sense Table of Contents. A great post for the WICED Sense is theWICED SENSE Kit BLOGwhich is like a WICED Sense quick start guide.
Some Android devices appear to have issues pairing to the WICED Sense Tag from inside the app, linked is a work-around that should allow you to connect to your Android device:WICED Sense Android Pairing Work-Around