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:




in particular the third and fourth arguments.


I call

uint16_t addr;

uint8_t cmdBuff[2];



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 */


                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