I2C Library issues

[M5M8S10]

Hello Forum,

the firmware of my P24Fj512GB610 MCU infrequently hangs up while communicating via I2C. I ran the program in debug mode and the .lst-file suggests, that when the MCU is stuck, the last entered function always was the mE I2C3_Stop() library-function, from which the MCU cannot exit. As far as i can read the instructions in the .lst-file, the MCU is endlessly polling the bit #7 of the MI2C3IF master interrupt flag. The problem occurs irregular and relativly rarly, but when it does, the firmware gets stuck completely. My question is, is there a time-out routine like the I2Cx_SetTimeoutCallback() function of PIC18 MCUs for PIC24 MCU or has anyone a suggestion of implementing one (there is no public reply on this post: viewtopic.php?f=106&t=75869, which asks basicly the same question)?
I already tried to implement a timeout by myself by setting a timeout before calling the I2C3_Stop() routine and dis- and reenabled the I2C module in case of timeout in a timer ISR, but with no success so far...

here is the function from which the troubleing I2C stop routine is called:

Code: Select all

function I2C_GetCntrVal():dword;                                                // pulls current counter value from Counter MCU
var
  HMSB,HLSB,LMSB,LLSB : byte;
begin
  // start communication by sending command
  I2C3_Start();                                                                 // issue start signal
  I2C3_Write(CntrMCU_ADDR);                                                     // write Address of Counter MCU
  I2C3_Write(I2C_CMD_GetCntr);                                                  // send Command to prepare subsequent counter value read-out
  // read counter value from counter MCU
  I2C3_Start();                                                                 // issue repeated start signal
  I2C3_Write(CntrMCU_ADDR + 1);                                                 // read address of Counter MCU
  HMSB := I2C3_Read(_I2C_ACK);                                                  // read higher MSB and ACK
  HLSB := I2C3_Read(_I2C_ACK);                                                  // read higher LSB and ACK
  LMSB := I2C3_Read(_I2C_ACK);                                                  // read lower MSB and ACK
  LLSB := I2C3_Read(_I2C_NACK);                                                 // read lower LSB and NACK
  I2C3_Stop();                                                                  // issue stop signal
  // form result (dword)
  Result := HMSB;                                                               // set to higher MSB
  Result := Result shl 8;                                                       // shift left 8
  Result := Result + HLSB;                                                      // add higher LSB
  Result := Result shl 8;                                                       // shift left 8
  Result := Result + LMSB;                                                      // add lower MSB
  Result := Result shl 8;                                                       // shift left 8
  Result := Result + LLSB                                                       // add lower LSB
end;

thank you,
Micha

[M5M8S10]

Update:

When I examined the I2C3CONL register the PEN bit (Stop Condition Enable bit) is still set. In a document for I2C communication for PIC24 MCUs from Microchip I read the PEN bit should be cleared automatically by the MCU and an interrupt should be issued, after initiating the stop-sequence by setting the PEN bit. I gues something similar happens within the library stop function.
The MCU continous its normal operation, when I set the master interrupt by setting the MI2CxIF bit manually, to generate the missing interrupt, when the I2C3_Stop() times out (via own written timer interrupt routine for time outs).

Weirdly, the ACKDT, ACKEN and RCEN of the I2C3CONL register are also set in addition to PEN bit. So maybe the the read instruction prior to the stop instruction was already faulty. On the other hand the I2C3_Read() routine, like the all other I2C library routines, are blocking calls, so I really do not know for sure.

I hope this can help folks with similar problems at least a little. Nonetheless, I am still open for clearification.

Regards
Micha