I2C from MQX to KSDK

[jblackston]

I'm working converting some old MQX I2C communication to the KSDK and I'm running into issues on how to format the request. In MQX I need to handle all of the ACK, NACK, and time delays to perform the read and writes. The KSDK seems to only have a single command so I'm not sure how to handle communication as I can't seem to get communication up. I've attached my code that opens and does reads and writes to the EEPROM. It includes my original code and also the code I tried to do communication via KSDK.

Original Attachment has been moved to: i2c-sample.c.zip

[jblackston]

Ok, I was able to run the eeprom example you sent me and after making a few modifications on the buffer read/writes I was able to get this to work. Thanks for the help.

[jblackston]

I'm going to be looking over the EEPROM example in the next day or so. Have a software release next week so I need to get that out of the way :smileyhappy: I'll let you know of my results as soon as I find out.

[Jorge_Gonzalez]

Hello Jason Blackston:

Please revise the code in the project shared with the next document:

KSDK I2C EEPROM Example

The project was for an old KSDK version but the use of the APIs should be the same.

Specifically about your code:

For ReadEEPROM():

- EEPROM I2C slave address is not required as part of the buffer. The slave I2C address is handled by the API if it is correctly specified in the device structure (i2c_device_t).

- Your both calls to _MasterReceiveData are redundant, you just need one call. Something like this:

    tempBuffer[0] = HIBYTE(address);
    tempBuffer[1] = LOBYTE(address);
i2c_ret2 = I2C_DRV_MasterReceiveData(I2C_EEPROM_DEVICE, &slave, tempBuffer, 2, (uint8_t*)bufferPtr, length);

or

i2c_ret2 = I2C_DRV_MasterReceiveDataBlocking(I2C_EEPROM_DEVICE, &slave, tempBuffer, 2, (uint8_t*)bufferPtr, length, 200);

If using the blocking API just pay attention to use enough timeout parameter to receive all data.

For WriteEEEPROM():

- I think the _MasterSendData calls are also redundant. One call should be enough to send EEPROM internal address and data buffer to write:

i2c_ret1 = I2C_DRV_MasterSendDataBlocking(I2C_EEPROM_DEVICE, &slave, tempBuffer, 2, bufferPtr, writeCount, 200);

- I do not see any delays. Usually EEPROM memories require some delays waiting for the write cycle to finish.

I hope this helps you to move forward.

Best Regards!
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jblackston]

Well, in the comment blocks before the 'return ' in the functions is the code that works with the MQX library. That's the issue I'm having with. When I send the commands with the ioctl commands I was able to handle the timing for both the reads and writes. I've been having issues trying to reproduce that with the KSDK stuff. the comment blocks are some of the variations I tried to perform but the return value from the function would be successful, or failed to ack, or lost arbitration... Of course when you get a successful response it turns out that nothing was received. So that's why I'm not exactly sure what I'm missing as the I2C functions seems to not having that much control like I had with the ioctl functions.

[Jorge_Gonzalez]

Hello Jason:

Sorry for overlooking your response.

Did you have a chance to look at the pointed EEPROM example and/or making my proposed changes?

It is true that the MQX I2C driver is different to the I2C driver in KSDK v1.x. The KSDK driver is aimed at typical use case of sending or receiving data frames (via Send and Receive buffers) and not so much in controlling the timing between bytes of a transfer. All about sending slave address, checking ACKs/NACKs, repeated start and start/stop signals is handled by the driver. If this kind of control does not fit your application then you need to create a custom driver.

About the API's response, for non-blocking APIs the successful response only means that the transfer (either send or receive) has started, but not that it has finished, so you need to check the status with I2C_DRV_MasterGetSendStatus() or I2C_DRV_MasterGetReceiveStatus().

Regards!

Jorge Gonzalez