Hercules RM46 – RM46 I2C hung-up for the external EEPROM via I2C

Hello Kuerbis,
We have recieve your post and get back to you shortly.

Hi Kuerbis-san,

  First, I'm not clear on your data flow. In your step 4, you have a comment thay says it means nIRS=0 then I2C is reset. What does this mean? Are you resetting the I2C by writing a 0 to the nIRS bit? Below is the TRM description about the nIRS bit. Please make sure nIRS is not written to 0 during a data transfer.

I2C reset enable bit
When set to 0, this bit will place all status registers in this module to their default state. Resetting nIRS during a data transfer can hang the I2C bus.

 Second, It wouldn't hurt to check the MST bit. The MST bit will be cleared by the hardware after the transfer is complete. But I doubt your hanging problem is due to the MST bit. You can try to check MST bit to see if it makes a difference. 

  Lastly, is it possible that the external EEprom is stretching the SCL during the low phase of the clock as a way to wait state the master? Check if the EEprom is stretching the SCL indefinitely which can also hang the bus. 

  

Hi Charles,

                                            

Thank you for replying.

I’m sorry for confusing you. They are resetting the I2C by writing a 0 to the nIRS bit at step 4. But I’ll confirm to them that they make sure nIRS is not written to 0 during a data transfer.

I also ask to them to check if the EEprom is stretching the SCL.

 

Thanks and Best regards,

Kuerbis

Hi Charles,

                                            

You said that Please make sure nIRS is not written to 0 during a data transfer.

How we can check it’s not during a data transfer?

Is it enough to check BB bit only? The customer wants to know this. MST bit is not reset at the same instant as the BB bit. So they asked If we need to check MST bit before reset I2C.

 

Thanks and Best regards,

Kuerbis

Hi Kuerbis,

 In your step 2, did you issue an 'acknowledge polling' command to the EEPROM to make sure the write is complete? Normally once the internally timed write cycle has started (as issued in your step 1), acknowledge polling can be initiated. The acknowledge polling make sure only if the internal write cycle has completed will the EEPROM respond with a zero allowing the subsequent read or write sequence to continue. Please check your EEPROM datasheet about the acknowledge polling.

 If a zero is returned after the acknowledge polling command then it means the write cycle is truly completed. You can then issue new command by polling the BB bit again to start a new command. I don't think you need to check the MST bit as it is not mentioned in the flowchart.  But you can try it to see if it makes a difference. 

Please also make sure you follow the below flowcharts for write and read operations assuming RM=1.

Hi Charles,

 

I need to confirm that they issue an 'acknowledge polling' command to the EEPROM to make sure the write is complete. But I don’t think they did. I guess they read NACK bit on I2CSTR to check an acknowledge.

 

Can we still use same scenario as below in case of read NACK bit on I2CSTR too?

 If a zero is returned after the acknowledge polling command then it means the write cycle is truly completed. You can then issue new command by polling the BB bit again to start a new command. I don't think you need to check the MST bit as it is not mentioned in the flowchart.  But you can try it to see if it makes a difference. 

 

BTW, I searched EEPROM which supports clock stretching option. But I couldn’t find it. I understand you mentioned the possibility of clock stretching. Do you know specific EEPROM which supports clock stretching?

 

Thanks and Best regards,

Kuerbis

 

Hi Kuerbis-san,

  I'm using a Microchip 24AA256/24LC256/24FC256 EEprom as a reference. Below is a description of about acknowledge polling. The NACK bit you read is before the STOP is issued. After the STOP is issued by the master the EEprom will initiate an internal write cycle. Please see below description and flowchart. In order for the master to know if the write is fully complete the master can issue an acknowledge polling command. If the device finishes the write then it will acknowledge.  If the device is still busy to complete the internal write cycle then it will return negative acknowledge. 

  I don't know if your sporadic hanging problem is due to this condition. But I think it is worth trying to make sure the internal write cycle is complete before you start a new command. 

  You should check your EEprom datasheet to see if it can stretch the clock. If it does not then we can rule out the hanging due to clock stretching. 

BTW, when you say hanging, what actually happened?

Hi Charles,

 

I also asked to the customer that when you say hanging, what actually happened?

But they told me that It's not known exactly how due to they have a low incidence of it.

 

OK. I understand that In your step 2, we have to issue an 'acknowledge polling' command to the EEPROM to make sure the write is complete.

 

I’ll ask to the customer to check EEPROM datasheet to see if it can stretch the clock.

Let me confirm about Microchip 24AA256/24LC256/24FC256.

I checked the datasheet of it.. There is no description of lock stretch. And SCL is input pin. So I think it couldn’t stretch the clock. Is my understanding correct?

 

Thanks and Best regards,

Kuerbis

Hi Kuerbis-san,
yes, the Microchip EEprom does not stretch the SCL clock. However, the I2C bus protcol supports it.

Hi Charles,

 

Do we have any specific timing to check ACK if the last byte data is performed correctly in Figure 15. Using Bit Polling for Master-Transmitter Operation, Repeat Mode (RM = 1)? I just worry if the polling could catch it to send next byte.

 

Thanks and Best regards,

Kuerbis

Hi Kuerbis,

  I don't quite understand the question. The ACK replied by the slave must meet the I2C electrical timing requirement specified in the device datasheet. The ACK is just a data bit to the master. It does not matter the ACK is for the last byte or the beginning of the byte. The ACK must meet the electrical timing in order for the master to properly sample the data. In the datasheet you will find setup and hold time requirement of the SDA with respect to the SCL if this is what you are looking for. What SCL frequency are you running?  Does frequency does your external EEprom device support?

Hi Charles,

 

I’m sorry that you are confused by my question,

We read I2CSTR to check ACK in Figure 15. I meant do we have any specific timing to read I2CSTR if the last byte data is performed correctly before send next byte?

 

Thanks and Best regards,

Kuerbis

HI Kuerbis,
Are you asking if you need to read the I2CSTR for each byte the master wants to send to the external device? Say you have 'm' number of words to send and if you need to read the I2CSTR for each word 'n' to send before 'n' = 'm'? If this is the question then the answer is no. If you look at the flowchart you will read the I2CSTR after n=m. If your question is if you need to insert some type of delay (i.e. adding NOP cycles) before reading I2CSTR after n=m then I don't think this is required if this is the timing you are referring to.