CC3235SF: I2C issues following SDK update

Sam

Part Number: CC3235SF
Other Parts Discussed in Thread: SYSCONFIG

Hello, we are working through the process of updating our SDK from 3.20.00.06 to (hopefully) 5.30.00.08. This has proved to be somewhat more involved than initially hoped, but most issues have been resolved. One still outstanding issue is regarding I2C transfers. We're using I2c to interact with the RTC, temp sensor, and accelerometer.

Previously, on SDKs 3.20 and 3.40.00.05, we were not experiencing any issues and I2C transactions worked as expected. Following the attempted SDK update, I2C transfers are not precisely failing (return status is true), however the values read during the transfer are not valid and writes (though it's difficult to say for sure, basing this off the values subsequently read, which are known to be incorrect) also seem to be inaccurate. We're currently finding this to be the case on both SDK 5.20 and 5.30 (not sure where in between 3.40 and 5.20.00.06 the break occurs though).

It's difficult to say where the issue is stemming from as the code in the I2C files has changed pretty substantially (for instance I2C_init used to contain actionable code rather than just exist as an empty function), however other e2e question/answers lead me to expect that the functionality should be the same without any required updates as I2C_transfer has been changed to handle all of that (though correct me if I'm wrong). And looking over the I2C code involved in the out_of_box demo project from SDK 5.30 doesn't lend any clues. Did something else change regarding the I2C setup process that needs to be taken into account?

Similarly, the changes to the sysconfig file, requiring GPIOs that could be previously set as 'Dynamic' to be classified as either 'Input' or 'Output' (with SDK 5.30 and sysconfig 1.10, at least) could be contributing... Maybe? Although I2C transfers don't seem to be functioning correctly regardless of the setting, so maybe not?

I'm not sure where I should be looking outside of these areas to solve this issue, or if I'm perhaps missing something obvious, so any help would be appreciated.

over 3 years ago

0 Sabeeh Khan1 over 3 years ago

TI__Mastermind 26840 points

Hi Sam,

I would encourage you to try the I2C examples from the CC3220 SDK on a launchpad. See if you can get those working, and then translate the new concepts into your existing project.

But yes, the GPIO modules has certainly changed. Everything should be done through Sysconfig, so it is not straightforward to simply use the latest SDK with an older project.

Are you running into build issues or have you already resolved those?

0 Sam over 3 years ago in reply to Sabeeh Khan1

Prodigy 110 points

Hi Sabeeh, we have no build issues and functionality seems to be good except when it comes to the I2C transfers. After looking into the issue more yesterday, it appears that when one of the other developers changed the I2C transfer mode from I2C_MODE_BLOCKING to I2C_MODE_CALLBACK, when trying to get the project to work. I think this explains the issues with I2C_transfer returning true as the status, but the values being read/written in the transactions not being valid. However, when I revert back to I2C_MODE_BLOCKING, it seems the I2C_transfer gets stuck in the I2C_transferTimeout trying to obtain a lock and the Watchdog Timer triggers before this happens (after 40 seconds) causing a reboot.

I've gone through and looked over the I2C in both the out_of_box demo project and the i2ctmp driver example, and cannot find any real differences in the implementation. This is the initialization code from the i2ctemp example

Fullscreen

1
2
3
4
5
6
    /* Create I2C for usage */
    I2C_Params_init(&i2cParams);
    i2cParams.bitRate = I2C_400kHz;
    i2c = I2C_open(CONFIG_I2C_TMP, &i2cParams);
    if (i2c == NULL) {
        Display_printf(display, 0, 0, "Error Initializing I2C\n");
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    /* Create I2C for usage */
    I2C_Params_init(&i2cParams);
    i2cParams.bitRate = I2C_400kHz;
    i2c = I2C_open(CONFIG_I2C_TMP, &i2cParams);
    if (i2c == NULL) {
        Display_printf(display, 0, 0, "Error Initializing I2C\n");

and our code is inline with that. Likewise our I2C_transfer code aligns as well. I would expect the issue to be part of the changes that happen to the GPIO settings in updated sysconfig, but then I'm surprised that the 5.20 SDK also exhibited the same issue.

+1 Sam over 3 years ago

Prodigy 110 points

Problem is likely solved, pending more extensive testing to be sure.

Issue caused by I2C_open failing to initialize/adequately check the I2C object mutex here:

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    /*
     * Create threadsafe handles for this I2C peripheral
     * Semaphore to provide exclusive access to the I2C peripheral
     */
    SemaphoreP_constructBinary(&(object->mutex), 1);
    /*
     * Store a callback function that posts the transfer complete
     * semaphore for synchronous mode
     */
    if (object->transferMode == I2C_MODE_BLOCKING) {
        /* Semaphore to cause the waiting task to block for the I2C to finish */
        SemaphoreP_constructBinary(&(object->transferComplete), 0);
        /* Store internal callback function */
        object->transferCallbackFxn = I2CCC32XX_blockingCallback;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    /*
     * Create threadsafe handles for this I2C peripheral
     * Semaphore to provide exclusive access to the I2C peripheral
     */
    SemaphoreP_constructBinary(&(object->mutex), 1);

    /*
     * Store a callback function that posts the transfer complete
     * semaphore for synchronous mode
     */
    if (object->transferMode == I2C_MODE_BLOCKING) {
        /* Semaphore to cause the waiting task to block for the I2C to finish */
        SemaphoreP_constructBinary(&(object->transferComplete), 0);

        /* Store internal callback function */
        object->transferCallbackFxn = I2CCC32XX_blockingCallback;

Seems like this should be checked to ensure it's not Null and if it is returning the whole object as Null (would have saved a lot of time). The mutex was null because this appears to have been implemented differently in earlier SDKs, and supporting static allocation didn't need to be enabled.

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
SemaphoreP_Handle SemaphoreP_constructBinary(SemaphoreP_Struct *handle,
    unsigned int count)
{
    SemaphoreHandle_t sem = NULL;
#if (configSUPPORT_STATIC_ALLOCATION == 1)
    sem = xSemaphoreCreateBinaryStatic((StaticSemaphore_t *)handle);
    if ((sem != NULL) && (count != 0)) {
        xSemaphoreGive(sem);
    }
#endif
    return ((SemaphoreP_Handle)sem);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

SemaphoreP_Handle SemaphoreP_constructBinary(SemaphoreP_Struct *handle,
    unsigned int count)
{
    SemaphoreHandle_t sem = NULL;

#if (configSUPPORT_STATIC_ALLOCATION == 1)
    sem = xSemaphoreCreateBinaryStatic((StaticSemaphore_t *)handle);
    if ((sem != NULL) && (count != 0)) {
        xSemaphoreGive(sem);
    }
#endif

    return ((SemaphoreP_Handle)sem);

Wi-Fi

Wi-Fi forum

CC3235SF: I2C issues following SDK update