Hi list,

I've been looking for the cause of an occasional software hang-up. Happens =
very=20
rarely in practice, but have found I can re-produce it at will by shorting =
I2C line(s) to=20
GND. This supports the observation that the problem has only exhibited whil=
e I was=20
physically handling a PCB ~ so probably an ESD transient corrupting I2C tra=
nsfer.=20

If it does ever happen in the field it wouldn't be great ~ it's a battery p=
owered device=20
with an LED (that the user probably can't see) that stays on causing consid=
erable=20
current draw when the problem manifests, with no way of resetting without r=
emoving=20
the batteries which requires tools. I'd like to the make the program recove=
r from this=20
auto-magically.

I went looking though the I2C code looking for places it could hang, e.g. w=
hile=20
statements. The following section of MCC generated code stands out as odd, =
within=20
the function I2C1_MasterTRBInsert()...
   =20
    // for interrupt based
    if (*pflag =3D=3D I2C1_MESSAGE_PENDING)
    {
        while(i2c1_state !=3D S_MASTER_IDLE);
        {
            // force the task to run since we know that the queue has
            // something that needs to be sent
            PIR1bits.SSP1IF =3D true;
        }
    }   // block until request is complete

The semi-colon after the while() terminates the while statement (if I'm not=
 mistaken).=20
That's strange, as the braces that follow, and comments, suggest the line=20
PIR1bits.SSP1IF =3D true was intended to be inside the while loop. As it wo=
uld be if=20
the semi-colon wasn't there, so perhaps it could be a simple typo.

I've updated MPLAB IDE X and MCC to latest versions, but generated code=20
remains identical to above.

Tried removing the semi-colon alone, program doesn't function properly at a=
ll. So if=20
the semi-colon was a typo, then it is just fortuitous that the code works b=
etter with it=20
than without it.

Tried removing the semi-colon and added an extra PIR1bits.SSP1IF =3D true; =
after=20
the while loop (closer to the what the code with the supposed typo would do=
), and it=20
seems to work better now. The I2C now works normally, still crashes with st=
imulus=20
as described previously but now in a way that no longer causes it to hang a=
t this=20
point. That's good - I can now work on making it recover fully from such a =
glitch.

I'm not fluent in I2C, so hard to believe I might have found misbehaving co=
de in the=20
MCC routines. I could and probably should use the WDT to recover from this =
and/or=20
other errors in a brute force kind of way, just have avoided using WDT so f=
ar as=20
device is battery powered and WDT would increase power consumption ~ though=
=20
I'm using a PIC18LF46K22 and believe I can turn the WDT off during sleep.

After sharing all this I feel more confident about solving the problem, but=
 still=20
appreciate comments, thanks for listening~!

Brent.

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.