• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 484 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.

RTOS/AM5728: I2C access from DSP

Ranganath V N
Intellectual 475 points

Part Number: AM5728

Tool/software: TI-RTOS

Hi,

I am trying to write  slave device on I2Cbus_3 DSP1, When we use the default i2c configurations with the transferMode as BlockingMode. Writing to the slave device taking taking around 4-5ms.

in the deafult i2c configurations interrupt is enabled, so we disable the interrupt with the blocking mode as the transfermode. Now the time it is taking to write in to the slave is 600microseconds.

we have  completely disabled I2c3 from the arm side. 

why it is taking soo much time to write/read with enabling the interrupt,  blockingMode as transfermode, bitrate of 400kbps. as bellow mentioned structure.

typedef struct I2C_Config_Params {

I2C_BitRate bitrate = 400kbps; 
I2C_TransferMode transferMode = I2C_MODE_BLOCKING;
void *transferCallbackFxn = NULL;

void *edmaHandle = NULL; /*! EDMA handle */

bool dmaMode  = false;

bool enableIntr = true; //when we make it false(polling method) we have observed that write time is 600microsec

}

what changes we have to do to write/read faster in interrupt enable mode? 

bios version: 6_52_00_12

pdk ver: pdk_am57xx_1_0_7

IPC version: 3_47_00_00

thanks

Ranganath

  • 0
    TI__Guru** 116780 points

    Ranganath,

    If you are using interrupt mode, is there a reason to use blocking mode in your usecase instead of callback mode? If you are using TI RTOS, please indicate if there is any other tasks running along with the I2C communication with the slave.

    You can use Timestamp provider routine or system aanlyzer view to check the ROV logs from the TI RTOS to check where the code is spending most of its time. At the moment, at a highlevel this does appear as though the driver SW spends longer than usual time in the ISR than when polling mode is used  but I can`t confirm without some profiling information.

    Also, curious to know why you indicated IPC version, Are you running any application on A15 core when performing this experiment. If you are running Linux, I would recommend running this as standalone DSP application using emulator and see if you can reproduce the same result. Linux uses power management driver that puts the core into low power state that has known to cause interrupt latency with GPIOs, UARTs, RTOS drivers running on the DSP.   

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 475 points

    Hi Rahul,

    thanks for your reply.

    Okay, we tried with the callback function, timing to read/write is reduced but after some transactions, we got a error number as -3. 

    i.e no ACK from the salve.

    we are calculating the timings as shown below 

    TIME_UNIT sl_i2c_start,sl_i2c_stop;
    i2c_start = GET_TIME_STAMP();
    I2C_transfer(i2cHandle, &transaction);
    i2c_stop = GET_TIME_STAMP();
    Log_print1(Diags_INFO, "____difference time mod____ = %d",(i2c_stop)-(i2c_start));

    we are observing that for

    1. TransferMode is callback mode with interrupt enable is 37microsec

    2.  TransferMode is  blocking mode with interrupt enable is 3-4milisec

    3.  TransferMode is  blocking mode with interrupt disable is 600microsec.

    For all the above conditions we have used Dsp standalone project so no need of linux and ipc is also not required.

  • 0 in reply to Ranganath V N
    Intellectual 475 points

    Hi, any updates on this particular issue???

  • 0 in reply to Ranganath V N
    TI__Guru** 116780 points

    Ranganath,

    Can you indicate what I2C slave is connected and what platform are you using for these tests. I would be able to comment better on the difference in performance if we have an ability to reproduce this issue at our end. Also, indicate what is the target time for latency that is acceptable for your usecase.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 475 points

    Hi Rahul,

    we are using the customized i2c slave device on the AM5728 DSP SYS/BIOS.

    Regards,

    Ranganath

  • 0 in reply to Ranganath V N
    TI__Guru** 116780 points

    Ranganath,

    DO you still need help with this issue or have you been able to make progress. Do you have a data sheet for the I2C slave so we can understand the expected signally and protocol  Is there some way that we can reproduce this with TI EVM. We only have I2C setup for communicating with EEPROM so not sure if there is a good way for us to reproduce your results.

    Regards

    Rahul