cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

How can I set the i2c clock frequency in SDK 2.0?

0 Likes
Reply
1 Solution
Anonymous
Not applicable

I am able to use cfa_bsc_OpExtended to access devices on the i2c bus for now, albeit at the fixed 400 kHz rate rather than a programmable rate. This is okay for my immediate needs.

I still think the i2cm driver was delivered broken. I cannot read/write anything on the i2c bus (both SCL and SDA remain high) using the i2cm driver when running on the Broadcom BCM20737TAG board.

View solution in original post

0 Likes
Reply
19 Replies
Employee

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.

0 Likes
Reply
Anonymous
Not applicable

Thanks!

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:

#include "i2cm.h"

In my create function, I call:

    i2cm_setSpeed(I2CM_SPEED_100KHZ);

    i2cm_init();

In my timeout function, I have:

    UINT8 accel[6];

    UINT8 areg[1];

  areg[1] = 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.

0 Likes
Reply
Anonymous
Not applicable

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?

0 Likes
Reply
Anonymous
Not applicable

Hello cdarling

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.

JT

0 Likes
Reply
Anonymous
Not applicable

Hello cdarling,

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?

Thanks

JT.

0 Likes
Reply
Anonymous
Not applicable

Hello cdarling,

Did dmiya answer your question?

Please let me know,

Thanks,

JT

0 Likes
Reply
Anonymous
Not applicable

When I run I2C with SDK1.0.1 following code worked.

---

UINT8 result;

UINT8 rx[0x01];

i2cm_init();

i2cm_setSpeed(I2CM_SPEED_100KHZ);

i2cm_setTransactionSpeed();

result = i2cm_read(rx, 0x01, 0x50 << 1);

---

I also could use cfa_bsc_OpExtended() like below.

---

CFA_BSC_STATUS result2;

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.

0 Likes
Reply
Anonymous
Not applicable

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.

0 Likes
Reply
Anonymous
Not applicable

Have you tried my code above?

I could use I2C without cfa_bsc_OpExtended() on both SDK 1.1 and 2.0.

0 Likes
Reply
Anonymous
Not applicable

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?

0 Likes
Reply
Employee

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.

0 Likes
Reply
Anonymous
Not applicable

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?

0 Likes
Reply
Employee

> 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.

0 Likes
Reply
Anonymous
Not applicable

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?

0 Likes
Reply
Employee

> We have an EEPROM physically connected to package pins 15/16

OK, patches and app are downloaded to NV.

> an SPI Flash on package pins 19, 20, 21, and 22

This is SPI2, the second instance of the SPI; OK to have it on P0-P3. So you are not loading app from serial flash.

> Then, there is no longer any activity on the I2C bus when I make calls using the i2cm driver.

Do you have another I2C slave connected to the bus? Or are you trying to access the EEPROM using i2cm API?

> 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?

No, they cannot interfere because these are entirely different pins. I was thrown off by your earlier question 'Is there something specific that needs to be done to reconfigure I2C after boot from serial flash?' - If SF is on physical pins 19-22, these are on logical pins P0-P3 which are entirely different from I2C pins.

0 Likes
Reply
Anonymous
Not applicable

> Do you have another I2C slave connected to the bus? Or are you trying to access the EEPROM using i2cm API?


There are other I2C slaves that I am trying to write/verify (read) on the I2C bus. Before switching over from BCM20732A0 and SDK 1.1, I had no problems reading and writing to the I2C bus using the i2cm driver. Now there is no activity on the I2C bus following boot from EEPROM.


I have been able to replicate the i2cm problem using the BCM20737TAG hardware, so this isn't related to our specific hardware platform. I created a very simple test by modifying the mybeacon sample application to make an attempt to write to the i2c bus every second, and observing i2c bus activity using an oscilloscope. Note that the cfa_bsc_OpExtended call generates activity on the i2c bus, while the i2cm call does not. i2cm always returns status=busy (2).


Do you see something missing in my i2cm initialization?



// application timeout handler (every second)

static void testApp_cb_appTimer(UINT32 arg)

{

       static int firstTime=1, timerCounter=0;

       UINT32 status = -1;


      if(timerCounter > 5){

            UINT8 data[1];

            UINT8 add1 = 0xF0;

            data[0] = 0xc0; // this is easy to see on the scope.

#ifdef USING_I2CM

            if(firstTime == 1){

                 // init i2cm

                i2cm_init();

                 i2cm_setSpeed(I2CM_SPEED_100KHZ);

                 i2cm_setTransactionSpeed();

                 firstTime = 0;

                 ble_trace0("\ntestApp_cb_appTimer() i2cm initialization complete.");

            }

   

            status = i2cm_write(data, 1, add1);

#else

// Write operation to the lower level driver is 1.

#define I2C_SLAVE_OPERATION_WRITE                   (1)

          status = cfa_bsc_OpExtended(data, 1, NULL, 0, add1, I2C_SLAVE_OPERATION_WRITE);

#endif

            ble_trace1("\ntestApp_cb_appTimer() i2cm_write() status=%d ", status);

       }

       timerCounter++;

}


0 Likes
Reply
Employee

Can you try disabling/removing:

i2cm_init();

i2cm_setSpeed(I2CM_SPEED_100KHZ);

i2cm_setTransactionSpeed();

The lower level driver will use the defaults it used for the EEPROM (400 KHz).

0 Likes
Reply
Anonymous
Not applicable

with those removed, scope shows that i2cm_write() still outputs nothing to the i2c bus, and always returns busy. This is running on BCM20737TAG hardware platform

0 Likes
Reply
Anonymous
Not applicable

I am able to use cfa_bsc_OpExtended to access devices on the i2c bus for now, albeit at the fixed 400 kHz rate rather than a programmable rate. This is okay for my immediate needs.

I still think the i2cm driver was delivered broken. I cannot read/write anything on the i2c bus (both SCL and SDA remain high) using the i2cm driver when running on the Broadcom BCM20737TAG board.

View solution in original post

0 Likes
Reply