• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 998 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2541: Long I2c Packet Causes Processor Hang

Bill Finger
Genius 3735 points
Other Parts Discussed in Thread: CC2541

I have a problem which I have found difficult to debug.  I have a CC2541 which I am using as a bridge between a downstream processor and a host device.  The CC2541 communicates with the processor via I2C, and the host via BLE.

The communication works great, unless the processor sends a large (~800 bytes) packet to the CC2541 via I2C.  Then, in some instances (not every time) the processor halts and stops servicing the I2C interrupts.  I can see the entire exchange via my logic analyzer; however, I cannot determine what is happening because the debugger loses synchronization with the device.

Anyone have any ideas?  I'm using 1.4.0 of the BLE stack and IAR 8.30.1.

Regards,

Bill

  • 0
    Guru 22270 points

    Hello Bill,

    An i2c packet of 800 bytes does seem quite large.  If you have the i2c set up as a Timer Event, it could be getting interrupted by the BLE Stack.  You can check the status code of the last transmission in the I2CSTAT register, particularly the Bus Error Condition.  Then you can have the CC2541 provide some kind of message.  The details are in the CC254x User's Guide swru191 http://www.ti.com/lit/swru191

    For hardware debugging, you can check to see the voltage level of the bus and which device is holding it high or low. If the traces for the SDA and SCL are not clean, then try changing the pull-up resistor values.  Also make sure the bus lines are as short as possible unless you are using an i2c buffer or isolator.

    If possible, send your data in smaller packets.  I suspect the processor is timing out.  You can also try changing the clock i2c clock rate to the highest rate. 

    There is also the function for critical events that you can try calling before you send the data: HAL_ENTER_CRITICAL_SECTION(intState) and HAL_EXIT_CRITICAL_SECTION(intState) after.  This may cause problems with your BLE connection but since you stated that the transfer is successful most of the times, then it shouldn't.

    The short answer is intermittent I2c failure is mostly bus related... most of the time.

    Thanks,

  • 0 in reply to Greenja
    Genius 3735 points

    Greenja,

    Thank you for your response.

    > If you have the i2c set up as a Timer Event

    I do not.  It is interrupt driven.

    > You can check the status code of the last transmission

    I cannot.  As I mentioned, the debugger's connection with the device is severed.

    > For hardware debugging, you can check to see the voltage level of the bus and which device is holding it high or low.

    The clock is being held low; I suspect very much it is the C2541 which is doing so.

    > If possible, send your data in smaller packets.

    This might be possible.  Are there some data available as to how much CPU I can use before I run into problems?

    >  I suspect the processor is timing out.

    What do you mean by that?  How can it time out?  I do not have the watchdog active.

    > You can also try changing the clock i2c clock rate to the highest rate. 

    I was actually thinking of turning it down.  Then the CPU would be interrupted less often, leaving more time for BLE stack management.

    Thanks again for your help.

    Regards,

    Bill

  • 0 in reply to Bill Finger
    TI__Mastermind 29650 points

    Bill,

    I suspect it might be due to either greenja's suggestions or:

    1: Critical sections in the stack where interrupts are disabled.

    These can last up to milliseconds and might cause buffer overflows in the I2C module but should not cause you to lose contact though.

    2: BLE stack stopping or dividing down the MCU clock during RF transmission

    See the HCI guide included in the BLE stack HCI_EXT_ClkDivOnHaltCmd / HCI_EXT_HaltDuringRfCmd. These are probably more likely.

    3: Device entering low power mode while receiving data.

  • 0 in reply to svendbt
    Guru 22270 points

    I think we will go with Svend suggestions on this one :)

  • 0 in reply to svendbt
    Genius 3735 points

    Sven,

    Disabling  HCI_EXT_HaltDuringRfCmd does appear to have solved the MCU halting problem.  I have other problems with lost bytes (that is, the byte count on the CC2541 does not match the number transmitted), but I think that is due to noise on the bus.

    Thanks again,

    Bill