AnsweredAssumed Answered

Strange behaviour in i2c driver (KSDK 1.3.0)

Question asked by Massimiliano Cialdi on Jun 16, 2016
Latest reply on Jun 22, 2016 by isaacavila

I use I2C_DRV_MasterReceiveDataPolling() that calls I2C_HAL_MasterReceiveDataPolling()

 

I find the docs:

drv.png

 

hal.png

in particular the third and fourth arguments.

 

I call

uint16_t addr;

uint8_t cmdBuff[2];

 

addr=0xf1ca;

cmdBuff[0] = (uint8_t)((addr>>8)&0xff);

cmdBuff[1] = (uint8_t)((addr>>0)&0xff);

I2C_DRV_MasterReceiveDataPolling(i2cEE_IDX, I2C_EEPROM_ADDRESS, cmdBuff, 2, pdata8, len);

 

Using a protocol analizer I can see that the first byte send by i2c (after the slave address), is correct, 0xf1. The second byte is not 0xca!

 

Debugging I follow the flow until I2C_HAL_MasterReceiveDataPolling() (lines from 440 in file fsl_i2c_hal.c):

 

   /* Send CMD buffer */

    if (cmdBuff != NULL)

    {

        while (cmdSize--)

        {

            if (!I2C_HAL_WriteByteBlocking(base, *cmdBuff--))

            {

                /* Send STOP if no ACK received */

                I2C_HAL_SendStop(base);

                return kStatus_I2C_ReceivedNak;

            }

        }

 

The point is the line 445. There is *cmdBuff--, so the first byte tranferred is correct, but the second is out of the buffer (ideally at index -1).

I wonder if it is a bug, because the same decrement is also at line 554 (I2C_HAL_MasterSendDataPolling()).

 

If it is not a bug, I have to pass the pointer to the last element of a buffer (strange and counterintuitive), and the documentation should specify this behavoiur.

 

Unfortunately the example shipped with KSDK1.3.0 doesn't help me

 

best regards

Max

Outcomes