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.
I'm now trying to use the i2cm library, but it doesn't seem to be doing anything (scope shows no action on the i2c lines, except for the occasional poll to the EEPROM).
I added in my include statements:
In my create function, I call:
In my timeout function, I have:
areg = 0xA8; // Start at OUT_X_L
i2cm_comboRead(accel, 6, areg,1, 0x30);
There are no other calls to i2cm. Any idea what is wrong?
I am using SDK 2.0 and probing the I2C pins on the i2c header of the BCM92073TAG board. When I used the cfa_* API, I was able to see i2c traffic on the bus.
I'd also like 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. I tried doing what you suggested here: Re: BCM20372S NVRAM Read/Write I2C Speed but it seemed to have no effect. Is this behavior different in SDK 2.x?
Sorry for the delay - The Carlsbad fires affected the San Diego area quite heavily as we were out for 2 days last week.
I am conferring with the I2C specialist now and will start on your CapTouch question as well.
I didn't get a chance to test the i2cm library on my board yet, but the I2C guys here believe that the GPIO's are not configured correctly using the i2cm library as they would be using the cfa_* API.
I assume that you are using the i2c_temperature_sensor.
We didn't make any changes to the I2C drivers in the SDK transition to 2.0.1.
Can you send me more of a code snippet to see if the I2C is being setup properly?
When I run I2C with SDK1.0.1 following code worked.
result = i2cm_read(rx, 0x01, 0x50 << 1);
I also could use cfa_bsc_OpExtended() like below.
result2 = cfa_bsc_OpExtended(rx, 0x01, NULL, 0x00, 0x50 << 1, CFA_BSC_OP_READ);
By the way, please check where you write 0xa8 to areg.
And slave address should be left-shifted.
Did dmiya answer your question?
Please let me know,
Is there any response from Broadcom on this question? We also have a quiet I2C bus after moving from SDK1.1 to SDK2.0 when making i2cm calls.
Should we be using cfa_bsc_OpExtended instead of i2cm calls? If so, then what is the purpose of i2cm? I did not see any of the sample applications in SDK 2.0 using i2cm.
Have you tried my code above?
I could use I2C without cfa_bsc_OpExtended() on both SDK 1.1 and 2.0.
Yes, I have tried your code above. It does not work for us. i2cm always returns status busy. Are you using 20732 or a different device? We are using 20732A1 w/ SDK2.0. Had no problems with 20732A0 and SDK 1.1.
Is there something specific that needs to be done to reconfigure I2C after boot from serial flash?
The I2C and SPI1 (used for serial flash) pads are muxed to the same physical pins on the SoC. So you cannot use I2C when using serial flash with SDK 2.0.1 (and with SDK 1.1.0 too - were you using EEPROM for storage instead?).
Support for using I2C when serial flash is used for storage is coming up in the next SDK release. But you still have to use some external component to isolate the I2C slave from the bus when an SPI transaction is ongoing.
We have an EEPROM on I2C bus. We can see SCL/SDA activity when the BCM20732 boots, but afterwards there is no activity and i2cm always returns busy status.
I saw a comment in one of the sample apps regarding reconfiguring the I2C interface after boot when running on 20732, but there was no source code to show what needed to be configured. I was not sure if this step was necessary for us to enable the I2C after boot.
Is there a BLE_PROFILE_GPIO_CFG that shows how to configure the I2C pins?
> We have an EEPROM on I2C bus.
So you are not using serial flash to store app + patches? If you are using serial flash, activity on the bus is expected, but these are SPI transactions, not I2C. Once SPI serial flash is detected, those pins are assigned SPI function, and cannot be reassigned to I2C (with the current SDK).
> I was not sure if this step was necessary for us to enable the I2C after boot.
If you use I2C EEPROM to store app code + patches, there is no need to configure I2C pins. If you use SPI serial flash, there is no API to reconfigure pins in the current SDK, the FW has to do this and this will be available only in the next 2.x SDK release.
> Is there a BLE_PROFILE_GPIO_CFG that shows how to configure the I2C pins?
BLE_PROFILE_GPIO_CFG only handles GPIO function mode (and not the other function modes of the same physical pins). So I2C cannot be configured using BLE_PROFILE_GPIO_CFG.
We have an EEPROM physically connected to package pins 15/16 and an SPI Flash on package pins 19, 20, 21, and 22 of the BCM20732A1 device. On boot, there is heavy activity on pins 15/16 as would be expected when booting from the I2C EEPROM. Then, there is no longer any activity on the I2C bus when I make calls using the i2cm driver.
The datasheet describes pins 15&16 as I2c bus, with alternative function for SPI, GPIO, and CTS/RTS for UART. Do you think the SPI flash we have on package pins 19,20,21, and 22 might somehow be interfering with the I2C bus alternative SPI functions?