• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 419 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.

CC2340R5-Q1: Issues during I2C Target Operation

sjmizuta
Intellectual 415 points

Part Number: CC2340R5-Q1
Other Parts Discussed in Thread: CC2340R5

Tool/software:

Hi. TI team.

When operating the CC2340R5-Q1 as an I2C target, issues are occurring. Can you identify any possible causes?

We use SDK version：8.40.

I added the I2C target function to the Basic BLE project's role based on the peripheral software.

Another IC functions as the master and reads out 5 bytes of data.

The CC2340R5-Q1 is able to output an ACK to the target address + R.

However, the ACK for the first byte of data is not being output by the other IC. There might be an issue with the other IC, but looking at the waveform of the SDA (see the red frame in the diagram below), it seems as though the other IC is trying to use the SDA at a low level, yet it remains at a high level.


Could you let me know what could be causing the issue if it originates from the CC2340R5-Q1? I'll also attach the code below.

void i2ctarget_trans(char* dunny)
{
    I2CTarget_Params i2ctarget_params;

    I2CTarget_init();

    I2CTarget_Params_init(&i2ctarget_params);
    i2ctarget_params.eventCallbackFxn = Callbackfxn_i2ctareget;
    i2ctarget_params.targetAddress = 0x42;
    i2ctarget_handle = I2CTarget_open(CONFIG_I2CTARGET_0, &i2ctarget_params);

    read_counter = 0;
    write_counter = 0;
    I2CTarget_start(i2ctarget_handle);
}


int_fast16_t Callbackfxn_i2ctareget(I2CTarget_Handle handle, I2CTarget_Event event, uint8_t *val)
{

    if(event == I2CTarget_Event_WRITE_RECEIVED) {
        read_buffer[read_counter] = *val;
        ++read_counter;
        return I2CTarget_STATUS_SUCCESS;
    }

    if(event  == I2CTarget_Event_READ_REQUESTED || event == I2CTarget_Event_READ_PROCESSED) {
        *val = write_buffer[write_counter];
        ++write_counter;
        return I2CTarget_STATUS_SUCCESS;
    }

    if (event == I2CTarget_Event_STOP) {
        BLEAppUtil_invokeFunctionNoData(i2ctaregt_fin);
    }

    return I2CTarget_STATUS_SUCCESS;
}


void i2ctaregt_fin(char* dunny)
{

    I2CTarget_close(i2ctarget_handle);
}

Best Regards.

  • 0
    TI__Genius 10095 points

    Hello, 

    From the image provided, I believe the SDA line is dropping lower than the "High" value like the rest of the waveform. 

    For instance, if you look that any time the SCL goes low, there is a drop a lower value before it recovers to the "low" value. Each time this occurs the SDA shows the same behavior. 

    I am going to talk to our hardware expert to see if there are any other concerns seen. The code looks good! 

    I will provide a response when I talk to the hardware expert, I should be able to provide a response tomorrow (04/14) or Wednesday (04/15). 

    Thanks,

    Isaac

  • 0 in reply to Isaac Larson
    Intellectual 415 points

    Hello Isaac.

    Thamks for the reply.

    Understood, I will wait.

    I look forward to your continued assistance.

    Best Regards.

  • 0 in reply to sjmizuta
    TI__Genius 10095 points

    Hello, 

    I have reviewed the waveform with our hardware expert and have confirmed the dip in the SDA line is the cause of some sort of noise or ringing on your SDA and SCL line. Do you have these two lines directly next to each other, or tightly wound together? 

    The master will provide the SCL, have you seen any other problems with this devices SCL? 

    Additionally, where are you measuring the waveform from and what is the voltage level for the waveform? 

    Are you able to check the TX buffer of the peripheral to see if an acknowledgement is queued? 

    Since the SCL is provided by the master, this is most likely a problem with the master IC as the SCL is not toggling for the acknowledgement. Additionally, since the peripheral is sending the data, the master would then send the acknowledgement. This seems like something wrong with the master. 

    Let me know if you agree, or if you have any other questions. 

    Thanks,

    Isaac

  • 0 in reply to Isaac Larson
    Intellectual 415 points

    Hello, Isaac.

    Thanks!

    Isaac Larson said:
    I have reviewed the waveform with our hardware expert and have confirmed the dip in the SDA line is the cause of some sort of noise or ringing on your SDA and SCL line. Do you have these two lines directly next to each other, or tightly wound together? 

    Indeed, upon reviewing it now, the red box in the diagram appears to show ringing. I have determined that it is unlikely to be related to the issue of the clock not being output.

    Isaac Larson said:
    The master will provide the SCL, have you seen any other problems with this devices SCL? 

    The master IC's I2C is a function we're using for the first time, so there are limited evaluation numbers, but no issues have been observed.

    Incidentally, when combining the master IC with the CC2340R5, there were no problems with the master IC's write operation.

    Isaac Larson said:
    Additionally, where are you measuring the waveform from and what is the voltage level for the waveform? 

    The wiring length is approximately 10 cm, and we're monitoring right around the midpoint.

    The high voltage level for both SCL and SDA is 3.3V, which is equal to the supply voltage.

    Isaac Larson said:
    Are you able to check the TX buffer of the peripheral to see if an acknowledgement is queued? 

    I apologize, but I don't understand that perspective.

    Could you please instruct me on the specific method and timing for this verification?

    Additionally, what information will this confirmation provide?

    Is my understanding correct that this will confirm whether the CC2340R5 is being instructed to switch to ACK reception mode?

    Best Regards.

  • 0 in reply to sjmizuta
    TI__Genius 10095 points

    Hello, 

    Disregard the last recommendation. After reviewing the TRM, I understand the acknowledgement structure for a target transmitting bytes to the controller. 

    The controller will give an acknowledgement to every byte sent by the target transmitter, besides the last byte. On the last byte, the target transmitter will release the SDA line and allow the controller to generate the stop or repeat start condition. 

    The controller controls the number of bytes sent from the target transmitter. Does the controller know the number of bytes being sent? It seems the controller believes the first byte sent is the last, thus no acknowledgement. 

    You can read about this in section 21.1.3.4 Acknowledgement in the I2C chapter of the CC2340R5 Technical Reference Manual. 

    Let me know if this helps. 

    Thanks,

    Isaac 

  • 0 in reply to Isaac Larson
    Intellectual 415 points

    Hello Isaac.

    Thanks.

    Isaac Larson said:
    The controller controls the number of bytes sent from the target transmitter. Does the controller know the number of bytes being sent? It seems the controller believes the first byte sent is the last, thus no acknowledgement. 

    The controller IC can accurately recognize the number of data because the number of data can be specified with the arguments of the provided library. Moreover, the fact that the SCL for ACK is not output is abnormal, so the NACK is likely unrelated to the issue.

    In any case, through this Q&A, it seems there is no problem with the CC2340, so we will continue to investigate the cause related to the controller IC.

    I will close this question.

    Thank you very much.