• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 408 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: I2C communication delay

ofirbo
Prodigy 220 points
Part Number: CC2541

Hi,

I have a custom board using the CC2541 chip, with two sensors attached to the I2C bus.

When reading data from sensor, I can see long gaps in communication, which I'm not used to working with different MCUs (TIVA, etc.).

It might be related to delays in I2CSTAT register update, since the I2C library is waiting between states (according to "Table 20-4. Master Receiver Mode" in user guide).

I need it in order to read data at high rate without affecting BLE connectivity.

//Read I2C registers
void i2c_read_registers(uint8 dev_addr,uint8 reg_addr,uint8 numBytes, uint8* spaceToWrite)
{
//Find device addresses
dev_addr_write = (dev_addr*2)|0x00;
dev_addr_read = (dev_addr*2)|0x01;
 
// Sent start condition and wait for it to be received
I2CCFG = I2C_SR;
waitI2CStat(SR_SENT);

// Send Device Address
I2CDATA = dev_addr_write;
I2CCFG = I2C_DO;
waitI2CStat(SLAW_ACK_SENT);

// Send Register address
I2CDATA = reg_addr;
I2CCFG = I2C_DO;
waitI2CStat(DATA_ACK_SENT);
      
// Send Restart condition
I2CCFG = I2C_SR;
waitI2CStat(RS_SENT);

// Send Device Address Read
I2CDATA = dev_addr_read;
I2CCFG = I2C_DO;
waitI2CStat(SLAR_ACK_SENT);

while(numBytes>1)
{
// Do Continued Transfer
I2CCFG=I2C_CO;
waitI2CStat(DATA_ACK_RECV);
*spaceToWrite = I2CDATA;
spaceToWrite++;
numBytes--;
}

//Do Final Transfer
I2CCFG=I2C_DO;
waitI2CStat(DATA_NACK_RECV);
*spaceToWrite = I2CDATA;

// Send Stop Condition
I2CCFG=I2C_SP;
}

Thanks,

Ofir

  • 0
    TI__Mastermind 27145 points

    Hi,

    I am trying to get an answer from a concerned engineer. We will get back to you ASAP. Please bare with us.

    Thanks,

  • 0
    TI__Mastermind 34890 points

    Ofir,

    Are you at least able to read accurate data? Could you zoom into the signal capture so the measurements are clearer? 

    In addition here are two E2E threads that covered similar delay issues. Please see the related threads here and here and test the suggested solutions.

    BR,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 220 points

    Seong Kim said:

    Ofir,

    Are you at least able to read accurate data? Could you zoom into the signal capture so the measurements are clearer? 

    In addition here are two E2E threads that covered similar delay issues. Please see the related threads here and here and test the suggested solutions.

    BR,

    Seong

    Hi Seong,

    The data from sensor (IMU) is read as expected. The problem is that I need to read it much faster in order to implement a descent 100 Hz control loop.

    I"m reading 12 bytes from sensor (3d acceleration and gyro), which should take after sending address and register for reading about total 16 bytes transactions - at a I2C clock rate of 533 [KHz] - less than 0.3 [ms].

    What's actually happens as can be seen in the figure I've attached - is that after each byte there is about 0.15 [ms] delay, which adds up to 4-5 ms unwanted delay.

    I didn't see in the other threads (or anywhere) a working signal capture which indicated continuous address-register-readout clocks, but I will check 

    HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_DISABLE_CLK_DIVIDE_ON_HALT );

    Thanks,

    Ofir

  • 0 in reply to ofirbo
    Prodigy 220 points

    ofirbo said:

    Seong Kim

    Ofir,

    Are you at least able to read accurate data? Could you zoom into the signal capture so the measurements are clearer? 

    In addition here are two E2E threads that covered similar delay issues. Please see the related threads here and here and test the suggested solutions.

    BR,

    Seong

    Hi Seong,

    The data from sensor (IMU) is read as expected. The problem is that I need to read it much faster in order to implement a descent 100 Hz control loop.

    I"m reading 12 bytes from sensor (3d acceleration and gyro), which should take after sending address and register for reading about total 16 bytes transactions - at a I2C clock rate of 533 [KHz] - less than 0.3 [ms].

    What's actually happens as can be seen in the figure I've attached - is that after each byte there is about 0.15 [ms] delay, which adds up to 4-5 ms unwanted delay.

    I didn't see in the other threads (or anywhere) a working signal capture which indicated continuous address-register-readout clocks, but I will check 

    HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_DISABLE_CLK_DIVIDE_ON_HALT );

    Thanks,

    Ofir

    Hi,

    Tried using the HCI_EXT_ClkDivOnHaltCmd function, no effect.

    Any ideas?

    Ofir

  • 0 in reply to ofirbo
    TI__Mastermind 34890 points

    Ofir,

    Here was the solution from the first suggested thread:

    "Interrupts are enabled inside interrupt handlers.  So, I had to disable interrupts inside the I2C ISR, or other interrupts would interfere.

    Secondly, if you reset SI and there is still an interrupt condition available, that interrupt may be missed.  To solve this issue I now loop until STAT  reads 0xF8 before leaving the ISR."

    BR,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 220 points

    Seong Kim said:

    Ofir,

    Here was the solution from the first suggested thread:

    "Interrupts are enabled inside interrupt handlers.  So, I had to disable interrupts inside the I2C ISR, or other interrupts would interfere.

    Secondly, if you reset SI and there is still an interrupt condition available, that interrupt may be missed.  To solve this issue I now loop until STAT  reads 0xF8 before leaving the ISR."

    BR,

    Seong

    Hi Seong,

    It seems that putting

    HAL_DISABLE_INTERRUPTS();

    before I2C read is indeed improving the time delay.

    Thanks,

    Ofir