I2C problem locking up / stuck on Curiosity PIC32MZEF development board

[Orunmila]

I am struggling to figure out how to work around what seems to be a silicon bug in the PIC32MZ2048EFM on A1 silicon. I am using the development kit DM320104.

From MPLABX I can see that the board I have is running A1 revision silicon. Looking at the Errata for the device I found that there is a silicon Errata on the I2C peripheral and I am hitting at least 2 of the described problems.

• False Error Condition 1: False Master Bus Collision Detect (Master-mode only) – The error is indicated through the BCL bit (I2CxSTAT).
• False Error Condition 3: Suspended I2C Module Operations (Master or Slave modes) – I2C transactions in progress are inadvertently suspended without error indications.

In both cases the Harmony I2C driver ends up in a loop never returning again. For condition 1 the ISR keeps triggering and I2C stops working and for condition 3 the driver just gets stuck.

I have tried to implement the workarounds listed in that Errata but I seem to have no luck. The Errata does not have an example, only a text description so I was hoping someone on here has tried this and can help me figure out what I am doing wrong.

Currently for condition 1 from the bus collision ISR we are clearing the ISR flag and the BCL bit and then setting the start bit in the I2C1STAT register, but the interrupt keeps on firing away and no start condition is happening.

Any idea what we are doing wrong?

[Orunmila]

Ok some feedback on this one.

The workaround in the Errata turns out does not work. The Errata claims you can

Quote

Clear the Master Bus Collision Detect (BCL bit (I2CxSTAT), after the bus returns to an Idle state. The software can monitor the S bit (I2CxSTAT) and the P bit (I2CxSTAT) to wait for an Idle bus. When the software services the bus collision Interrupt Service Routine and the I 2C bus is free, the software can resume communication by asserting a new Start condition.

But this does not work at all.

We clear BCL and wait for both S and P bits to be 0 but this never happens and we end up waiting forever.

As an attempt to work around this we decided to try to reset the entire module, this means that we set the ON bit in I2CxCON to 0 to disable the module, this resets all the status bits and resets the I2C state machine, once this is done we wait 4 clock cycles (since the second workaround in the Errata suggests we should wait for 4 clock cycles) and then we set the ON bit back to a 1. This clears the BCL error condition correctly and allows us to continue using the peripheral.

We have not yet tried to implement the workaround with the timeout that resets the I2C peripheral if it becomes unresponsive without warning, that will be coming up next, but it does seem like that will work fine as it will also disable the entire module when the condition happens which seems to clean out the HW state machine which it looks like is the culprit here.

The I2C peripheral section 24 of the family datasheet can be found here http://ww1.microchip.com/downloads/en/devicedoc/61116f.pdf

 

[Orunmila]

Some advice for Microchip:

If this was my product I would stop selling development kits with A1 or A3 silicon to customers. I2C is widely used and it will create a really bad impression of the product's reliability if customers were to evaluate it with defective silicon.

And please fix the Errata, your workaround for I2C Issue 1 does not work as advertized !

[saidattu32]

Hi,

I am also getting the same problem . I2C is randomly hanging in checking for IDLE state and i checked for flags where ACKEN =1. So i applied reset sequence(9 clock pulses) and bus become IDLE. Now the problem is after some time , Read Time Out errors is coming i.e RBF = 0. I2C Receive buffer(I2C3RCV) is not filled completely. Even i reset with a relay the I2C master is still in the same state. what to do to get out from this problem? Please help..  

 

Controller: PIC32MZ1024EFH144

IDE: MPLABX IDE v5.10

Silicon Version: A1

[Orunmila]

I was not able to create a satisfactory workaround on the A1 or A3 Silicon. We were able to get Rev B2 Silicon which resolves the problem. The official workaround on A1 silicon is not to use the peripheral but instead to bit-bang the I2C.

From the Errata:

 

[scum]

The errata workarounds works for me.

Usually, the problem is not the workaround, but when i2c module hangs, it do this in the middle of the actual data transmission. In addition of ic2 module hang, it causes I2C bus stuck somewhere in the middle of data transmision..

So, when you detect I2C module hang, you should reset module and generate I2C bus recovery sequence: 9 ...18 clocks, and stop bit.

I'm not sure if you can do this with I2C module enabled, so you can disable module, clear all fail bits in status register, switch SCK and SDA pins to GPIO mode, generate bus recovery seq., enable I2C module and start the transmission from the beginning as usually.

 

[Orunmila]

Can you be a bit more specific with that information please? Which Silicon revision are you using? Also we were able to get the workaround to work at some temperatures but it was not working correctly across the voltage and temperature range permitted in the spec. How did you test that it worked?