Hot!Bug: PIC32 I2C driver may lockup at DRV_I2C_TASK_SET_RCEN_ONLY on Master receive

New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2018/10/01 17:36:13
  • Location: Tokyo
  • Status: offline
2018/10/02 21:14:14 (permalink)
5 (1)

Bug: PIC32 I2C driver may lockup at DRV_I2C_TASK_SET_RCEN_ONLY on Master receive

I2C driver may lockup at DRV_I2C_TASK_SET_RCEN_ONLY on Master receive operation, if interrupt service routine of any other driver has higher priority than I2C.

Harmony v2.06
XC32 v1.42 free mode

I configured Harmony to use USB-CDC interrupt mode driver and I2C Master interrupt mode dynamic driver with bit-rate 100 kHz. Harmony configurator set USB interrupt priority higher than I2C as default.

The object program worked almost fine, but sometimes I2C driver stoped at DRV_I2C_TASK_SET_RCEN_ONLY state for 1+16 bytes transmit/receive I2C call in heavy load condition on both I2C and USB.

Such lockup was able to be released by calling DRV_I2C_Tasks() just once from application level, which "lost interrupt" was suspected.

Also, if I changed interrupt priority of I2C driver higher than USB, this lockup didn't happen.

Possible cause:
This problem may be caused by calling SYS_INT_SourceStatusClear() AFTER issuing PLIB_I2C_xxx() command to I2C controller in DRV_I2C_Tasks().

For example, in "case DRV_I2C_TASK_PROCESS_READ_ONLY:", the driver calls PLIB_I2C_ReceivedByteAcknowledge( i2cId, true/false ), and then calles SYS_INT_SourceStatusClear(dObj->mstrInterruptSource) just before returning from DRV_I2C_Tasks().

If any higher interrupt arouses between those two calles, and if it takes longer time than usual, ReceivedByteAckowledge might complete before SYS_INT_SourceStatusClear()  call. The last interrupt will be lost by such SourceStatusClear() call.

ReceivedByteAcknowledge completes in about 10 micro seconds at 100kbps standard I2C, which is rather short time for other interrupt service routine to finish.

As described in the reference manual (*1) I2C interrupt is "pulse", which means periphral does not latch it. Only interrupt controller latches the interrupt status. If such status is cleared, unserved interrupt, if any, will be lost.

I moved SYS_INT_SourceStatusClear(dObj->mstrInterruptSource) related block to just before switch(dObj->task) block, then problem was fixed. But, formal verification test is needed for such changes.

Also, more investigation is needed for slave interrupt and error interrupt, but I haven't done them, yet.
I'd like have future release of Harmony to include fix for this issue.

*1 Document reference:   24.4.2 I2C Interrupts
   PIC32 Family Reference Manual
   Section 24. Inter-Integrated Circuit(tm)
   DS61116F (c) 2007-2013 Microchip Technology Inc

   By the way, this document is missing from the document list on Microchip device page for PIC32F250F128B...


0 Replies Related Threads

    Jump to:
    © 2019 APG vNext Commercial Version 4.5