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.

problems about the I2C on the DM648

Hi,everyone:

       we use the DM648 as a slave to communicate with an ARM through the I2C, and the rate is 100kbps. However, sometimes the I2C of DM648 will not send the ACK bit to the ARM(Figure 1 below). this problem is very serious when arm send data to DM648 often(for example , every300ms). what causes this and how to solve it?

  Figure1  the wave on the SCL and SDA(yellow--SCL, blue--SDA)

Below is our configuration:

PSP_I2cConfig I2C_devParams =

{PSP_OPMODE_INTERRUPT, //interrupt mode

 0x5D, //own address

8,//Number of bits/byte to be sent/received

100000,//I2C Bus Frequency. 100kbps

108000000,//module input clock freq. 108MHz

FALSE,//7bits/10bits Addressing mode

FALS//Digital Loop Back(DLB)mode enabled

}; //this parameter is used in the tcf file 

below in our program:

1)create:

GIO_Handle i2cHandle = NULL;

i2cHandle = GIO_create("/I2C0",IOM_INOUT,&status,NULL,&gioAttrs);

if(NULL == i2cHandle)

{

  //restart

}                                              
2) read

{

PSP_i2cDataParam buf;

size_t size = 1;

Int retCode = 0;

Uint8 *inputbuf = NULL;

 

inputbuf = (Uint8 *)MEM_calloc(extHeap,256,64);

if(NULL == inputbuf)

{

    //error

}

buf.i2cTrans.buffer = inputbuf;

buf.i2cTrans.bufLen = 256;

buf.i2cTrans.flags = PSP_I2C_READ|PSP_I2C_IGNORE_BUS_BUSY;

buf.i2cTrans.param = NULL;

buf.timeout = SYS_FOREVER;

size = 1u;

retCode = GIO_read(i2cHandle,&buf,&size);

}

besides, we use pspdriver_1_10_00_09and bios_5_31_02

 

 

  • Maoyang Wu,

    Other than the display from the I2C protocol analyzer, what indication do you have of a problem? Does the write operation complete successfully? Does the ARM report a problem?

    What signal level do you expect the ACK bit to have? The blue SDA waveform in your picture shows a logic level of 0 during the final SCL clock pulse when the ACK/NACK bit is expected.

    Regards,
    RandyP