I2C hardware on Kinetis KL03 never stops receiving data when single stepping.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I2C hardware on Kinetis KL03 never stops receiving data when single stepping.

Jump to solution
852 Views
rickstuart
Contributor V

Noticed when single stepping through I2C code on a Kinetis KL03 processor connected to an EEPROM that as soon as the debugger executed the line to read the I2C data buffer the hardware continued to read byte after byte from the EEPROM even though the debugger had stopped.

During the I2C transaction a START is sent by the Master KL03 followed by the Address of the Slave EEPROM and the Internal Register Address to be read from the EEPROM.   A Restart is then sent followed by the Address of the Slave EEPROM.  But this time with the READ bit set.  This is followed by a "dummy" read to clear the I2C read buffer of the just sent Address of the Slave EEPROM.  This triggers a byte read from the EEPROM.  Prior to this the ACK bit in the KL03 is set such that after the EEPROM sends data it will continue sending data.  (If the ACK bit in the KL03 is not set the EEPROM would not send any additional data.)  If the KL03 program continues to execute code would detect when the current transaction is done then clears the ACK bit such that after the next read the EEPROM will stop sending data to the KL03. 

However, if we stop the code right after the 1st read of the I2C receive buffer the KL03 hardware will continue to clock out byte after byte from the EEPROM. Despite the fact the debugger has stopped.

It was expected that the KL03 would not clock out any additional data from the EEPROM until the next read of the I2C receive buffer.

I am not sure if this is a hardware bug, the expected behavior or if there is a configuration problem.  Does anyone else know?

Tags (2)
0 Kudos
1 Solution
639 Views
mjbcswitzerland
Specialist V

Hi

This is a bug in the I2C controller of various devices as reported and confirmed here:

KL43 I2C problem 

There are quite a number of threads about problems with the double-buffered I2C design if you search the forum.

See appendix A of http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf for more details and solutions to the operation.

Regards

Mark

Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts

View solution in original post

0 Kudos
2 Replies
640 Views
mjbcswitzerland
Specialist V

Hi

This is a bug in the I2C controller of various devices as reported and confirmed here:

KL43 I2C problem 

There are quite a number of threads about problems with the double-buffered I2C design if you search the forum.

See appendix A of http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf for more details and solutions to the operation.

Regards

Mark

Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts

0 Kudos
639 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Rick stuart,

   Could you please also post some relate codes, and debug picture, I2C wave form for my analysis?

 

Waiting for your reply!


Have a great day,
Kerry

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

0 Kudos