HI
I am using Kenitis K10 Cortex m4 CPU on our board , when it was taken as a SMBUS slave device .
I checked all the registers of I2C and SMBUS , but still cannot find how this slave device check whether it is the final byte in the transfer from the master device, when it is in receive slave mode.
Could you know which bit in the registers means the slave device receives a stop signal? and would the STOP signal issue a individual interrupt ?
thanks a lot.
Hi,
There is an application note AN4342 about Kinetis I2C/SMBUS communication process.
Please check here to download related software.
Wish it helps.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I use the kinetis as the I2C slave , when in slave receive mode , how can it know the received byte is the last one ??? the problem not sloved.
In stm32 cpu , it is very clear that we can use the STOPF bit in the status register , but in the kinetis , seems no such kind of signal , who can help find the answer ?
Hi Alven,
You can use the I2Cx_S[BUSY] bit to check if the current I2C communication continue or stopped.
Wish it helps.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi I also noticed this bit , but I am still confused about its usage. Currently the kinetis CPU in I2C slave mode receives data through the I2C interrupt , if I want to whether it is the last bit, is it suppose to check this bit after receiving every byte?
or after receiving every bit , wait for some time , and then check this bit in the interrupt ?
Hi Alven,
I checked the updated Kinetis product(such as K64 chip) I2C module provides STOPF flag for last byte checking.
While, based on current I2C module, I would suggest after each byte received, waiting for 2bit time to check the BUSY bit status. The BUSY bit checking routine should be out of the I2C interrupt service routine. The waiting time (2bit I2C) could use a timer to generate related timer interrupt, then in timer ISR to check the BUSY bit state.
Wish it helps.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
HI Mike
thanks for your suggestion, I am using KINETIS K10 , which doesn't have
STOPF flag. And I tested checking the BUSY bit in the i2c interrupt
routine after receiving last byte , seems it failed . So as your
suggestion, if the slave i2c needs to know whether it is the last byte, it
has to set up a timer in the i2c interrupt routine after receiving each
byte?
and another question is after a transfer finishing , if the mater starts
another transfer immediately, which means the I2C slave receives a start
signal immediately and change its BUSY bit to 0, in this case, is it
possible to fail to check the BUSY bit?
Have a good day.
Alven
Hi Alven,
Your concern is quite reasonable.
Using BUSY flag isn't robust for software design.
The I2C slave could use NACK to completion the transaction.
Please check below description at K10 reference manual:
I would recommend customer to set I2C Slave receiver data buffer with fixed number. When received byte number equal to the Max. RX Buffer size. I2C Slave need to send NACK to completion the transaction.
Then I2C master will know, the I2C slave couldn't receive any more bytes and stop the current transaction.
I2C master will start next round transaction for left bytes.
Wish it helps.
best regards,
Mike
hi Mike ,
As you said , i'v fallen into big trouble for I2C since the slave might get unaccounted bytes from master as the command. If we turn to K64 , can we use the STOPF bit to detect the final byte in a slave mode ?
Hi Alven,
I don't think there with big trouble for I2C communication.
For there could set a communication protocol for Master TX with Slave RX, after the slave address following byte is transfer size value. Then I2C slave will know how many bytes I2C master will send.
The same issue also will happen with I2C Master RX with I2C Slave TX. If there with transfer size value setting, the I2C master couldn't know how many bytes I2C slave will transfer.
Yes, the K64 I2C module STOPF bit will trigger the I2C interrupt, please check below description about I2C interrupt flag:
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Alven
Hi Alven
You can use clock stretching feature at I2C Slave code.
Here are more details on I2C clock stretching. I2C is a bi-direction open-drain interface, always clocked from the master. But the slave can also drive the clock line low, delaying the clock edges as needed, and therefore stretch the clock period. This use case is when the master first writes to a slave on the bus, and uses the read command. The master then provides the clock edges for the read, and the slave is supposed to respond with its data during those clock edges. If the slave is not ready to respond when the master expects to receive the data, the slave can drive the clock line low and stretch the clock until it is read.
How to use clock stretching?
I2C Slave only written I2C data register when the slave has something to transmit.
Wish it helps.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
HI Mike
As your introduction , it would be great , if we can make use of clock stretching feature. But I could find the detailed information about how to use it in the Kinetis user reference.
When the slave get a read operation in the interrupt process, but the data has not been prepared or need some time to prepare, how to use a clock stretching in a interrupt routine? which register can be set to inform the master that the data has not been ready? and when the master gets it , will it initialize another read operation after a while ?
Have a good day, you are really helpful!
Best Regards
Alven
Hi Alven,
When I2C master want to read data from slave, if the I2C slave doesn't write any byte to I2C Data I/O register (I2Cx_D), the SCL line will be hold low with I2C slave. Then I2C master will know I2C slave is preparing the data (clock stretching happens). From I2C slave aspect, I2C Slave only written I2C Data I/O register (I2Cx_D) when the data is ready.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
HI Mike
When a master initialize a read operation , on the slave side, it is already in the write interrupt mode, but the data has not been prepared at that time. Do you mean when data is not ready , the slave device should quit this interrupt routine firstly or prepare the response data in the interrupt routine ? I guess these two ways are difficult to implement in a real-time operation system
Hi Alven,
The slave device need set a flag(variable) indicated pending for data response and then quit the interrupt routine ASAP.
When slave device prepared data ready, the slave device just write data to I2C data register in task.
Wish it helps.
Have a great day,
Mike
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
hi Mike ,
thanks for your patience.
You mentioned when the data has not been prepared , the slave side should quit the write interrupt routine Asap.
Does it mean this write operation failed ?
If no , at that time, should it clear the the register interrupt flag and wait the master to initialize another read operation ? or when data is ready in the slave mode by the application, the application should put the data directly in the data register and then clear the interrupt mode to continue the last write operation?
thanks.
Best Regards
Alven
Hi Alven,
Does it mean this write operation failed ?
No. It need to clear the register interrupt flag at first. Then after the data ready, the application should put the data directly in the data register (clock stretching happens).
best regards,
Mike
hi Mike
I have tested it. when the data is not ready , the slave quits the interrupt and clear the register interrupt instead of putting the data into the data register , it seems another write operation interrupt comes immediately and tries to get the data again. should the slave side do anything before the data has been prepared????
Best Regards
Alven
Hi Alven,
During I2C slave initialization, do you set the I2Cx_C2 register [SBRC] bit? Please try to add related code to set this bit.
If possible, could you provide the I2C communication signal for analysis? Thanks.
Best regards,
Mike