• AVR Freaks

Helpful ReplyHot!Harmony 2.03b I2C issue PICMZ - Silicon Errata

Page: 123 > Showing page 1 of 3
Author
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
2017/05/12 15:33:31 (permalink)
0

Harmony 2.03b I2C issue PICMZ - Silicon Errata

I'm working with PIC32MZ2048EFM100 Rev. A1 and I'm having Master Bus Collision issues periodically. Bus speed is 100 khz (I've tested also 50 Khz and 10 kHz) and I'm not able to figure it out. I've tested a workaround using this code in IntHandlerDrvI2CErrorInstance ISR function:
 

 
void __ISR(_I2C1_BUS_VECTOR, ipl5AUTO) _IntHandlerDrvI2CErrorInstance0(void)
{
 
     SYS_ASSERT(false, "I2C Driver Instance 0 Error");
 
 
 
     I2C1STATbits.BCL = 0;
     I2C1STATbits.IWCOL = 0;
     I2C1STATbits.I2COV = 0;

     IFS3bits.I2C1BIF = 0;
     DRV_I2C_Bus_Clear (sysObj.drvI2C0);
}
 

 
DRV_I2C_Bus_Clear function was introduced in Harmony 2.03b. The above workaround is effective 9 times on 10 but sometimes I2C stops and there is no way to recover the BUS. It's very tricky to debug, I have to wait 10 hours or more to catch a bug to test this workaround.
 
I've also tested bitbanged mode, but since my application is running at 50 Mhz, I've some problems of jitter of other tasks. It happens because timer interrupt used by I2C in bitbanged mode cause a overhead on the code. In the 2.02b Harmony version bitbanget I2C was not working perfectly (there was some issues with DRV_I2C_TransmitThenReceive function).
 
I want to test PIC32MZ2048EFM100 Rev. A3 that seems to have solved I2C issue, but I cannot find any feedback about it. Does anyone have experienced the same problem? Is there a real workaround? Does the A3 works better than A1? Is there any news about the roamap for releasing the new B1 revision?
 
I need to go ahead, since this project shoud go in production very soon and I have nomore time. I'm very frustrated about this issue. I already spent a lot of resouces to get rid of a problem in USART driver.
 
CF
post edited by Johnny0099 - 2017/05/13 13:18:44
#1
Aiden.Morrison
Super Member
  • Total Posts : 729
  • Reward points : 0
  • Joined: 2005/02/25 11:18:31
  • Location: Canada
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/12 16:13:44 (permalink) ☄ Helpfulby Johnny0099 2017/05/13 14:18:59
0
Johnny0099
I'm working with PIC32MZ2048EFM100 Rev. A1 and I'm having Master Bus Collision issues periodically. Bus speed is 100 khz (I've tested also 50 Khz and 10 kHz) and I'm not able to figure it out. I've tested a workaround using this code in IntHandlerDrvI2CErrorInstance ISR function:
 

 
void __ISR(_I2C1_BUS_VECTOR, ipl5AUTO) _IntHandlerDrvI2CErrorInstance0(void)
{
 
     SYS_ASSERT(false, "I2C Driver Instance 0 Error");
 
 
 
     I2C1STATbits.BCL = 0;
     I2C1STATbits.IWCOL = 0;
     I2C1STATbits.I2COV = 0;

     IFS3bits.I2C1BIF = 0;
     DRV_I2C_Bus_Clear (sysObj.drvI2C0);
}
 

 
DRV_I2C_Bus_Clear function was introduced in Harmony 2.03b. The above workaround is effective 9 times on 10 but sometimes I2C stops and there is no way to recover the BUS. It's very tricky to debug, I have to wait 10 hours or more to catch a bug to test this workaround.
 
I've also tested bitbanged mode, but since my application is running at 50 Mhz, I've some problems of jitter of other tasks. It happens because timer interrupt used by I2C in bitbanged mode cause a overhead on the code. In the 2.02b Harmony version bitbanget I2C was not working perfectly (there was some issues with DRV_I2C_TransmitThenReceive function).
 
I want to test PIC32MZ2048EFM100 Rev. A3 that seems to have solved I2C issue, but I cannot find any feedback about it. Does anyone have experienced the same problem? Is there a real workaround? Does the A3 works better than A1? Is tere any news about the roamap for releasing the new B1 revision?
 
I need to go ahead, since this project shoud go in production very soon and I have nomore time. I'm very frustrated about this issue. I already spent a lot of resouces to get rid of a problem in USART driver.
 
CF




 
Hi there - some history on the revisions and I2C>
 
The original PIC32MZ series (PIC32MZEC etc.) had these problems in all versions.  The PIC32MZEF revision A1 was released with the eratta but with a note in the errata that it would be fixed in the next silicon revision.  As I recall revision A2 was never released and revision A3 still has the problem.  A microchip rep. mentioned on the forums that I2C3 had been cannibalized to lend parts to fixing the other I2C hardware as well as using some spare gates/cells in the design, but that it still didn't fix it.
 
I vaguely recall reading that the I2C can sometimes get so badly stuck that one has to disable the module then 'manually' generate a stop condition for an extended period, return the bus to idle, and then re-enable the I2C peripheral before continuing but I can't find a link to that now.
 
Personally I have avoided using I2C on some designs because I am suspicious this problem manifests even below 100 kHz.
#2
NKurzman
A Guy on the Net
  • Total Posts : 17618
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/12 17:58:47 (permalink)
4 (1)
I am using the H/W I2C at less than 100KHz and for small amounts of data.  I an not seeing any issues with an PIC32MZ2048EFH144
#3
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 00:13:18 (permalink)
0
Hi NKurzman,
 
what silicon revision are you using?
#4
NKurzman
A Guy on the Net
  • Total Posts : 17618
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 00:58:42 (permalink)
3 (1)
A question better asked A few hours ago.
Ask again on Monday
#5
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 04:47:27 (permalink)
0
I have on my desk two lot of PIC32MZ2048EFM100 samples and need to make some other boad prototypes to test A3 revision. I'm not able to understand what HW revision are from package marking.
 
Here's data printed on both:
 
LOT 1: PIC32MZ2048EFM100    Code: 1551AR8
LOT 2: PIC32MZ2048EFM100    Code: 1648GHV
 
Does someone knows how to get the HW revision from these codes?
 
#6
Aiden.Morrison
Super Member
  • Total Posts : 729
  • Reward points : 0
  • Joined: 2005/02/25 11:18:31
  • Location: Canada
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 05:43:29 (permalink) ☄ Helpfulby Johnny0099 2017/05/14 01:31:50
0
Johnny0099
I have on my desk two lot of PIC32MZ2048EFM100 samples and need to make some other boad prototypes to test A3 revision. I'm not able to understand what HW revision are from package marking.
 
Here's data printed on both:
 
LOT 1: PIC32MZ2048EFM100    Code: 1551AR8
LOT 2: PIC32MZ2048EFM100    Code: 1648GHV
 
Does someone knows how to get the HW revision from these codes?
 




I think you have to connect them to the programmer to identify the revision - those codes do tell you the year and week of production 1551 is 2015 week 51, while 1648 is 2016 week 48 or very recent.  I would guess the 1648's will be A3 though.
#7
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 13:23:32 (permalink)
0
Can't connect to programmer since these devices are not already on the board. I need to understand if they are A3 before mounting on PCB.
#8
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 13:48:23 (permalink)
3 (1)
Looking at Errata Document:
 
Rev C Document (7/2016)
Updated to include silicon revision A3.
Updated silicon issues 2. Module: (Oscillator), 6. Module: (I2C), and 11. Module: (ADC).
Added silicon issues 13. Module: (ADC), 14. Module
 
A3 revision was added to Errata on July 2016.
 
Marking Code: 1648GHV means production date 2016 week 48 (end of november), so it should be revision A3. But I need to be sure before mounting the boards.
#9
Aiden.Morrison
Super Member
  • Total Posts : 729
  • Reward points : 0
  • Joined: 2005/02/25 11:18:31
  • Location: Canada
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/13 15:31:35 (permalink)
5 (1)
Johnny0099
Looking at Errata Document:
 
Rev C Document (7/2016)
Updated to include silicon revision A3.
Updated silicon issues 2. Module: (Oscillator), 6. Module: (I2C), and 11. Module: (ADC).
Added silicon issues 13. Module: (ADC), 14. Module
 
A3 revision was added to Errata on July 2016.
 
Marking Code: 1648GHV means production date 2016 week 48 (end of november), so it should be revision A3. But I need to be sure before mounting the boards.




Use nitric acid to dissolve the casing and upper metal and a high powered scope to read the revision off the die?  Alternately put in a ticket to support to ask.  I'm sorry I can't offer a better solution but I really don't know other than using the programmer.
post edited by Aiden.Morrison - 2017/05/13 15:49:50
#10
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/14 01:30:47 (permalink)
4 (2)
I'm going to use x-ray to look for differences on the die in the I2C zone :-)
 
Anyway, I've already opened a ticket to support and sent an e-mail to my local FAE, hope will receive a reply soon.
post edited by Johnny0099 - 2017/05/14 01:34:04
#11
thackerp
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2012/01/18 12:25:44
  • Location: Chandler, AZ
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 04:19:05 (permalink)
0
They're both A1.
#12
GDA
Junior Member
  • Total Posts : 82
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 08:33:23 (permalink) ☄ Helpfulby Johnny0099 2017/05/15 15:18:07
0
Johnny0099,
 
 
The DRV_I2C_Bus_Clear function is blocking. Also, you have to make allowances in your application code to resend any message which might be in process. I had a test set up where I could get the problem to happen in a few minutes. By setting a flag inside the Bus interrupt, I was able to add code to my application (which was checking for the transaction to complete) to detect this flag and use the DRV_I2C_Bus_Clear function to reset the I2C bus. However, I also had to clear / reset several internal values and use the DRV_I2C_QueueFlush function in order to get my state machine to reliably resend the transaction. After this change, I was able to run the test for more than a week without detecting the problem.
 
 
Having said that, I cannot guarantee your situationi is identicle to mine. But I recommend moving the Bus Clear function out of the interrupt. It is blocking. I also recommend using the Queue Flush function to cancel out your previous transmission. Then the only thing left should be sto simply resend it.
 
 
I hope that helps.
#13
NKurzman
A Guy on the Net
  • Total Posts : 17618
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 13:37:55 (permalink)
0
NKurzman
A question better asked A few hours ago. 
Ask again on Monday

 
 I have A1 Chips.
#14
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 15:16:36 (permalink)
0
@thackerp
 
is there a way to get A3 chip samples?
#15
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 15:25:50 (permalink)
0
GDA,
 
really usefull your suggestion, I will try to call the DRV_I2C_Bus_Clear function outside the Error Interrupt ISR and  reset the state machine by calling the DRV_I2C_QueueFlush function. Did you use the DRV_I2C_Bus_Clear function as it is or did you write a non blocking one?
 
Will let you know if this workaround can solve my issue.
#16
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 16:36:52 (permalink)
4.5 (2)
Johnny0099
...
Did you use the DRV_I2C_Bus_Clear function as it is or did you write a non blocking one?

You can't. The peripheral is locked up, so you have to bit bang the pins to manually clear the condition.
You'd have to create a state machine triggered by a timer to do it in a non-blocking fashion, and not use the peripheral until it finished.
 
#17
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 23:06:51 (permalink)
0

You can't. The peripheral is locked up, so you have to bit bang the pins to manually clear the condition.
You'd have to create a state machine triggered by a timer to do it in a non-blocking fashion, and not use the peripheral until it finished.

 
It's clear to me that the pheripheral is blocked and need to bit bank to unlock. Just trying to understand if make sense to rewrite the DRV_I2C_Bus_Clear function in a non blocking fashion. Before this I need to find a valid workaround.
#18
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/15 23:49:03 (permalink)
0

The DRV_I2C_Bus_Clear function is blocking. Also, you have to make allowances in your application code to resend any message which might be in process. I had a test set up where I could get the problem to happen in a few minutes. By setting a flag inside the Bus interrupt, I was able to add code to my application (which was checking for the transaction to complete) to detect this flag and use the DRV_I2C_Bus_Clear function to reset the I2C bus. However, I also had to clear / reset several internal values and use the DRV_I2C_QueueFlush function in order to get my state machine to reliably resend the transaction. After this change, I was able to run the test for more than a week without detecting the problem.

 
I'm trying in this way:
 

/* Clear error */
if (i2c_error == true)
{
DRV_I2C_OBJ *dObj = (DRV_I2C_OBJ*)sysObj.drvI2C0;
SYS_INT_SourceStatusClear(dObj->mstrInterruptSource);
DRV_I2C_Bus_Clear (sysObj.drvI2C0);

if ( (PLIB_I2C_BusIsIdle(dObj->i2cId)) &&
(!(SYS_INT_SourceStatusGet(dObj->mstrInterruptSource))) )
{
_DRV_I2C_InterruptSourceEnable( dObj->mstrInterruptSource ) ;
_DRV_I2C_InterruptSourceEnable( dObj->errInterruptSource );
dObj->task = DRV_I2C_TASK_SEND_DEVICE_ADDRESS;
PLIB_I2C_MasterStart(dObj->i2cId);
}

i2c_error = false;
}

 
i2c_error is flagged in the I2C error ISR.
 
Not so much different from the previous situation. Works 8 times or more, but sooner or later the I2C does't restart. Will do some debug to understand what is happening.
#19
GDA
Junior Member
  • Total Posts : 82
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/16 10:12:38 (permalink)
0
I'm not sure I understand the second if block in that code.
 
Also, I am a little concerned about the PLIB_I2C_MasterStart.  That will cause a start signal.  The transmit function does this for you.
 
1: When you say "I2C does't restart" do you mean you no longer see toggles on the SCL and SDA lines?  Do you see either of them as stuck low?
2: If the lines go back high after the bus clear, then something inside the driver is at issue.  I suspect that you may need to clear the queue.  
 
If the hardware sticks with one of the lines held low, then the peripheral will refuse to start as it thinks the bus is not idle.  However, if you call the transmit function and the driver fails to send data to the peripheral, it may be waiting for a previous transmission to complete even though that transmission was canceled.  The Queue Flush function should clear the Queue.
 
The Bus Clear function could be written as a state machine.  However, as qhb suggests, you'd need some way to time the signals.  You would also need some way to continue to run the state machine until it is finished.  qhb's suggestion implies using a timer and its interrupt for both purposes.  You cold also simply call a state machine function which used the core timer value for timing and just continue to call it until it completed.
 
I hope this helps.
#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2019 APG vNext Commercial Version 4.5