Strange behaviour in i2c driver (KSDK 1.3.0)

[mastupristi]

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];

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

[isaacavila]

Hello Max,

They told me that this fix was added in latest release (I think they refered to internal one and they've not uploaded to SDK builder yet).

Meanwhile you can use the provided fixed source file.

Regards,

Isaac

[isaacavila]

Hello,

Development team told me that this bug is fixed in latest KSDK 1.3 version. Also, they provided me the fixed source file with this change (replace the -- by ++). I am attaching this file in case anybody want to check it.

Regards,

Isaac

[mastupristi]

Good,

which version of KSDK is? 1.3.1? I  just downloaded the 1.3 from SDK builder but it still contains the bug.

Where can I find the latest 1.3 version.

best regards

max

[isaacavila]

Hello Max,

This site is for internal use, but I gave you the number for this event in case you would ask for solution in this topic, you can refer to this topic by using KPSDK-11169.

Have a nice day!

Regards,

Isaac

[isaacavila]

Hello,

In fact, I already reported this issue, this is the report number KPSDK-11168.

Have a nice day!

REgards,

Isaac

[mastupristi]

unfortunately sw-jira.freescale.net seems to be unknown by DNS. I cannot reach it.

Also sw-jira.freescale.net at Website Informer. Visit Sw Jira Freescale.​ says that the site is dead

best regards

Max

[DavidS]

Hi Max,

Looking at your post and it seems logical that the *cmdBuff-- should be incremented (i.e. *cmdBuff++) rather than decremented.

Have you tried changing it?

Regards,

David

[mastupristi]

of course!

I have tried to increment and it works perfectly

And I tried to pass pointer to the last element of the buffer and it also works correctly.

So this is a bug in the source code, or is a bug in the docs.

It is strange that the decrement is replicated in two functions.

But it is also strange that no one noticed the problem until now.

And finally, if it is not a bug, it is strange to pass pointer to the last element of an array, and that this behaviour isn't undocumented.

best regards

Max

[DavidS]

Hi Max,

Thanks for noticing it, and testing workaround.  I will make sure the KSDK_1.x team know about this.

Sorry for the troubles.

Regards,

David