• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1515 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.

I2C of CC2541 shows erroneous spikes at SDA, SCL

Thomas Treyer
Prodigy 240 points
Other Parts Discussed in Thread: CC2541, CC2540

I want to use the HW-based I2C peripheral of the CC2541 as master. Therefore I connected a scope to SDA and SCL to prepare a measurement setup for debugging later on. I was very surprised when I saw spikes every 20 ms; I did not write my I2C code yet. I implemented already a GPIO IRQ every 20 ms; therefore I assume these spikes are a result from the CC2541 terminating sleep (PM2). Without sleep there are no spikes.

Normally both SDA and SCL are "high" (no activity at I2C). During a spike both SDA and SCL go simultaneously to "Low" for exactly 250 ns. This is definitely no start or stop condition. 

I tried all possible settings of the P2 configuration registers, but no setting showed any influence to these spikes.

Currently it seems that my I2C slaves will not be distracted by these spikes; but I am not sure what happens if such a spike will fall into an I2C write or read telegram.

Question 1: Did anybody observed these spikes, too?

Question 2: Is it possible that the CC2541 I2C peripheral will transmit a byte over I2C during sleep (PM1 or PM2)? Or is the CC2541 active always during I2C activity?

Kind regards

Thomas Treyer

  • 0
    Prodigy 10 points

    Thomas,

    "Question 1: Did anybody observed these spikes, too?"

    Yes, we are seeing these spikes after coming out of PM2.

    Have you found a solution to this problem or a work-around?

    Thanks,

    SP.

  • 0 in reply to eric rabinowitz
    Prodigy 20 points

    Thomas,

    "Question 1: Did anybody observed these spikes, too?"

    Yes, we are seeing these spikes after coming out of PM2.

    Have you found a solution to this problem or a work-around?

    Thanks,

    SP.

  • 0 in reply to eric rabinowitz
    Prodigy 240 points

    At the moment we blame our hardware, especially the power supply decoupling.

    Theory: When waking up from PM2 the chip starts to supply the I2C block with power. Due to bad power supply decoupling it takes too long for the I2C power supply voltage to ramp up and the first clock pulse is processed wrong from the I2C block, resulting in a spike of exactly one clock period.

    Background: We first used a BLE module for the CC2540 with integrated power supply decoupling. There we had no problems with the power supply. Then we switched to another BLE module, the PAN1721 with CC2541. Here we observed several problems including the problem of the I2C spikes. This module seems to have no or less integrated power supply decoupling. 

    In the moment we are changing the hardware and we will receive new prototypes in the next two weeks. Then we will see what happens. But I am confident to solve the problem with the new hardware, because we made tests with our SW running at an eval board from TI (SensorTag), where we observed no problems and no spikes.

    Recommendation: I recommend to test your SW with another hardware, too.

  • 0 in reply to Thomas Treyer
    Prodigy 20 points

    From TI:

    "This is a hardware bug.

    If override enable (the OVR bit in the I2CWC register) is set to 1 before entering PM2 and the clear when returning to active mode, the glitches disappears and the actual I2C functionality will be unaffected.

    To be on the safe side, also we recommend that you also write the reset values to the I2CCFG, I2CDATA and I2CADDR before clearing the OVR bit."

  • 0 in reply to Shannon Petty
    Intellectual 910 points

    I am also seeing this problem exiting from PM3.

    The result is it hangs the I2C.

    Looking at the ERATA Note for the CC2541, it suggests a work around for PM2 but doesn't mention if this also works for PM3. (I've tried it but hasn't made any difference).

    Can TI comment on the actual cause of the glitches, and if there is a time frame associated with them. Certainly we've encroached on the problem as the software has evolved. Thus I am thinking these glitches perhaps occur on a given time frame - which I am now just hitting.

    Regards

    Rob