CCS: cc2640 i2c isn't recovering from error

shiran rivka lavi

Prodigy 110 points

Other Parts Discussed in Thread: CC2640

Tool/software: Code Composer Studio

Hi,

I have a problem that the i2c is stack, I saw the register when it happens MSTAT:

BUSBSY 1

IDLE 1

ARBLST 1

DATACK_N 1

ADRACK_N 1

ERR 1

BUSY 0

I tried to close the i2c, init and open it but nothing help, the i2c isn't recovering.

Please help me to figure it out.

Thanks, Shiran.

over 7 years ago

0 Toby over 7 years ago

TI__Mastermind 35070 points

Hi,

Please see the following related content:
- e2e.ti.com/.../578663
- processors.wiki.ti.com/.../Adding_BLE_Enabled_RTOS_Task

Regards,
Toby

0 Toby over 6 years ago

TI__Mastermind 35070 points

- Are you trying to use I2C w/ the BLE stack?
- Are you ever able to successfully (initialize and) use the I2C?
- Are there any pin conflicts?
- Is the CC2640 actually connected to an I2C slave? If so, does the I2C slave interface successfully with any other I2C master?

Please provide the above information for further support.

Regards,
Toby

0 shiran rivka lavi over 6 years ago in reply to Toby

Prodigy 110 points

- Are you trying to use I2C w/ the BLE stack? - On the same controller we are using the BLE stack.
- Are you ever able to successfully (initialize and) use the I2C? - Yes
- Are there any pin conflicts? - No
- Is the CC2640 actually connected to an I2C slave? If so, does the I2C slave interface successfully with any other I2C master? - Yes

Actually the connection is functioning well if reading the device every 1-2 sec. When the read is every 100mSec we can see the problem.

0 Christin Lee over 6 years ago in reply to shiran rivka lavi

TI__Guru 56405 points

What's your I2C setting? Are you using blocking mode?
Can you post code snippet regarding how you integrate I2C to BLE examples?

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

Hi Shiran,

Which SDK version are you using? This could be related to the known (and fixed) issue in the I2C driver where calling close could set the I2C hardware into a "false busy" state.

The root cause of the issue is simply unexpected activity on the I2C lines which makes the hardware think it received a start condition even tho it did not. In the old driver version this could occur during I2C_close() as the I2C pins were released. The fix however only solves the issue on the driver side where "close" caused it, it does solve if this happens due to external interference/misbehaving I2C slaves.

As the I2C hardware does not provide an reset mechanism, you need to fully power cycle the I2C hardware to recover, which means turning on and of the whole domain. This means that you should be able to recover by simply going in and out of standby.

0 shiran rivka lavi over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 110 points

Thanks, I Know this issue, but the error that the i2c got in to is 0xFF (unknown error) and not busy error.

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

Hi Shiran,

Just to clarify, which status are you referring to in this scenario?

0 shiran rivka lavi over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 110 points

The i2c get 0xFF error, mostly got out of this error at the next i2c transfer command, (I'm reading every 500 milsec).

But there are time where the i2c isn't get out of the 0xFF error, and only resetting the BLE can help.

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

Hi Shiran,

I meant, which value are your reading out more precisely as the transfer function typically only returns a boolean.

0 shiran rivka lavi over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 110 points

you are right that I can't see the error code from the transfer function which returns a Boolean value.
I debugged it and saw where it gets the error.

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

In that case, could you elaborate on where in the code you are reading this exactly?

0 shiran rivka lavi over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 110 points

In I2CCC26XX, I2CCC26XX_hwiFxn, line 486:

else {
/* Try to send a STOP bit to end all I2C communications immediately */
/*
* I2C_MASTER_CMD_BURST_SEND_ERROR_STOP -and-
* I2C_MASTER_CMD_BURST_RECEIVE_ERROR_STOP
* have the same values
*/

I2CMasterControl(hwAttrs->baseAddr,
I2C_MASTER_CMD_BURST_SEND_ERROR_STOP);

/* Do not post SWI here to avoid subsequent transfers being stopped.
Wait till the stop condition interrupt to post SWI */
}

0 shiran rivka lavi over 6 years ago in reply to shiran rivka lavi

Prodigy 110 points

In the start of this case, there is this command:
/* Some sort of error happened! */
object->mode = I2CCC26XX_ERROR;

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

Hi Shiran,

Which SDK do you currently use? Could you try to use the I2C driver from the latest CC13x0 or CC2640R2 SDK?

0 shiran rivka lavi over 6 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 110 points

I'm using simplelink_cc2640r2_sdk_1_50_00_58

0 IUsedToBeARealPerson (M-W) over 6 years ago in reply to shiran rivka lavi

TI__Guru 58425 points

As that SDK contains quite old drivers, I would suggest you try migrating to the 2.30 SDK or at least use the I2C driver provided in the newer SDK to get the latest bug fixes. It is very likely that this issue already is addressed in your case.

Bluetooth®︎

Bluetooth forum

CCS: cc2640 i2c isn't recovering from error