This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C Interrupt problems on CC2541

Other Parts Discussed in Thread: CC2541

Hi,

I have been trying to implement an I2C slave on a CC2541 device which has the Peripheral + Observer profiles implemented on it. I am testing the I2C functionality while the device is just observing constantly without establishing any connections to any other device around it. As a matter of fact, there is no other BLE devices around the device.

One thing I discovered is that the following function seems to block the I2C interrupt detection for some reason.

VOID GAPObserverRole_StartDiscovery(DEFAULT_DISCOVERY_MODE, DEFAULT_DISCOVERY_ACTIVE_SCAN, DEFAULT_DISCOVERY_WHITE_LIST);

The above function calls the following function, which is within the BLE stack library and I do not have access to it.

GAP_DeviceDiscoveryRequest( );

When I comment out the call to GAPObserverRole_StartDiscovery(), the I2C interrupts fire and work exactly as I want them. Each I2C request coming from an external master is detected and responded to by the CC2541 slave device as needed.

After observing the above, I decided to call the GAPObserverRole_StartDiscovery() function less frequently. That way the device could scan for a few hundred miliseconds and then wait for a few hundred miliseconds doing nothing. In this idle period, the I2C interrupts would be detected and serviced.

The above had limited success. When the device is started up, the I2C interrupts do get detected and serviced as required for about 20 seconds. Then the I2C interrupts get blocked again. The interrupts are never detected after that.

Does anybody know why the above may be happening? Is there any "hidden" I2C or global interrupt disabling within the stack that I should be aware of? Any feedback from users who have seen a similar problem will be greatly appreciated.

I am guessing that other stack functions must be kicking in after the first 20 seconds that cause this blocking. I will try to hunt these down while I wait for a response to this post. I will give my updates if I come across anything interesting during my tests.

Regards...

  • I have done more testing on this issue and have made the following observations:

    1 - No matter what the frequency of scanning and pausing is sooner or later the CC2541 Key Fob gets into a state where all of the I2C interrupts are blocked.

    2 - Changing the scan stop period (the hold off period) and the scanning duration changes the reliability of receiving the I2C interrupts during the first 20 to 30 seconds when the I2C interrupts are detected successfully. If the hold off period is significantly larger than the scanning duration, the I2C interrupt reliability definitely improves. When this ratio gets smaller, I2C interrupts are detected intermittently and I can see the failure rate increases.

    3 - The I2C interrupts are ALWAYS detected reliably everytime the code is restarted. The I2C interrupts fail gradually as the code is left running for 20 - 30 seconds.

    I think what I am seeing here is due to a bug within the GAPObserverRole_StartDiscovery() function (to be specific the actual problem is likely to be in the GAP_DeviceDiscoveryRequest() function which is called by the GAPObserverRole_StartDiscovery() function) that has the side effect of blocking the I2C interrupt detection for some reason. Over time, each call to GAP_DeviceDiscoveryRequest() may be deteriorating the workings of the registers that end up in the failure of the I2C module as I have described.

    My suspicion is that I2C is not used very often in the CC2541 Key Fob and this bug has probably not been detected yet. However, if anyone has come across similar issues on the I2C operation, please share it here.

    If any TI employee can provide a feedback on the level of I2C testing that has been carried out for the Observer role, that will be really helpful.

    Regards...

  • Hi Cryptoman,

    Have you found the origin of this I2C issue? And if yes, how did you solve it?

    I am encountering some strange behaviors with the I2C as a slave.

    Best regards

  • Hi,

    It has been a long time since I have completed that project. I have not managed to sort out that I2C issue unfortunately. I am not sure whether there has been HW/SW updates since I have left the project. It may be worth searching for more up to date posts and problems on the I2C issue.

    Good luck!