The "project" is to have one PIC32 talking to another over i2c.  Something I
have done many times over the years.  The "new thing" is the PIC32
hardware.  As usual, I'm not sure where to post, since the intersection of
knowledgeable people, PIC32, and i2c is pretty small.  But I like you guys
the most.  And this will probably end up as documentation, more than help.

A "project" or "adventure" is usually a clear idea of steps to take, with
the expectation that it will take a few days; but then insert some problems
or issues, and each of those will take a day (or more) in itself.

A word about the PIC32 i2c engine.  They have a Master and a Slave, both of
which operate simultaneously.  On the same pair of pins (thus, on the same
bus).  This could be construed as a feature.  For one thing, you can write
master and slave code and do all your testing without having to wire up
anything (except two pullup resistors).  It has some interesting
implications if you get involved with multi-master devices, and want to try
making a device that can be a master and a slave at the same time.  The
downside is that you cannot turn off one side or the other, and if you have
a problem, you can't separate the blame by disconnecting the suspect side.

The first adventure went like this: I worked up some master code (always
easier) that would poll all the addresses from 0x10 to 0xEE.  This is
tradition, and it's a very valuable exercise.  "Polling" means you send a
start, an address, get the ack, and then stop.  No data is sent, and the ACK
tells you if there is anything at that address.  So far, so good.  Now I
start to work on the slave.  Getting an interrupt routine to execute is an
adventure in itself, and not part of this discussion.  Let's just say I got
that to happen.

The problem then was, I would get one interrupt (when the slave saw its
address) and then nothing afterward.

I enabled the "bus collision" interrupt.  I also examined the error bits.
No answers appeared.

The only clue that I had was that after halting the program (to look at
registers), and then hitting continue, it would then receive one more
interrupt before disappearing again.  (Disappearing = not ACKing its
address).  In the old days, this meant "R/M/W bug".   Good guess, but not
this time.  The other thing that it means is "When you stop, you read all
the registers".

Turns out, I have to read the "received byte".  Remember I said no data was
transferred.  But...
 - Even though it's just an "address match", the 8 bits from that address
byte went into the I2C_RCV register.
 - This also sets BF (buffer full).
 - The slave hardware refuses to do anything else until you read that
character.
 --Even after successive attempts to address that slave:
 - No collision errors are set, and no collision interrupts are generated.
 - The I2COV (overflow) bit never sets.
 - The reception of a STOP does not clear the character, reset BF, or free
up the slave in any way.

The solution is as simple as making sure to check BF and read whatever got
received, but getting there was tricky.  I also surmise that this "poll"
packet is not usually thought of, considered, or otherwise documented.  It
is real, though.  This is, for example, how you're supposed to determine
that an EEPROM is done writing.

I have to go work on the current problem...

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