Been there, done that, and be glad that at least the macro for the reserved
addresses actually was setting a bit that had to do with the reserved
addresses!  And thanks for the warning on that one, since I haven't seen it
yet.

What I do is to make it equivalent to another macro of my own, such as
#define I2C_IGNORE_RESERVED_ADDRESSES  that I can use in my code so that it
looks and acts proper.

Perhaps this is someone getting their revenge on those of us who ignore the
reset defaults and go about setting each and every bit on our own.  It's
even more fun because there are two or three ways to set configuration bits
from a program.

The one I came across a few years ago had to do with the UART break
function and the transmit polarity.  Although in retrospect, maybe this was
some leftover trick from parts that didn't have a break function...they
probably turned the TX upside down to produce a break.  Or something.  I'll
just drop the label UART_TX_PIN_NORMAL here in case someone with a search
engine is looking for answers (and I have a habit of finding my own posts
in a search like that).

This is why I stick to open source as much as I can.  I can't imagine
trying to fix stuff like this with a service ticket.  I usually end up
explaining the bug to them after I find it, instead of the other way around=
..



On Sun, Mar 31, 2013 at 2:16 AM, veegee <veegee@veegee.org> wrote:

> On 2013-03-31 5:07 AM, veegee wrote:
> > Hi all,
> >
> > I'm testing the I2C functionality on the PIC32MX220F032B with the
> > i2cdetect program on a Raspberry Pi. i2cdetect simply prints out a tabl=
e
> > of all found addresses on an I2C bus. The slave address of my PIC is
> 0x42.
> >
> > For some reason, if I configure the I2C module on the PIC *without* the
> > I2C_USE_RESERVED_ADDRESSES flag to I2CSetSlaveAddress, i2cdetect shows
> this:
> >
> > Note that the meaning of I2C_USE_RESERVED_ADDRESSES according to the
> > Microchip PIC32 I2C library is: "Disable reserved address protection,
> > allowing responses to reserved addresses (violates I2C specification) "=
..
> >
> > # i2cdetect -y 0
> >
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> > 00:          03 04 05 06 07 -- -- -- -- -- -- -- --
> > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- --
> > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 70: -- -- -- -- -- -- -- --
> >
> > Note the unexpected 0x03, 0x04, 0x05, 0x06, and 0x07 addresses being
> > detected.
> >
> >
> > But if I *do* pass the I2C_USE_RESERVED_ADDRESSES flag like so:
> >
> > I2CSetSlaveAddress(
> >       I2C1, 0x42, 0,
> >       I2C_USE_7BIT_ADDRESS | I2C_USE_RESERVED_ADDRESSES
> > );
> >
> > i2cdetect shows what I expect:
> >
> > # i2cdetect -y 0
> >
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> > 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- --
> > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 70: -- -- -- -- -- -- -- --
> >
> >
> > When I tested the same functionality on a PIC18F26K22, the behaviour wa=
s
> > as expected, with only 0x42 showing up without any special reserved
> > address use configuration flags. But for the PIC32, the behaviour seems
> > to be the opposite of what I expect.
> >
> > Can anyone shed some light on this?
> >
>
>
> I figured it out. There's yet another bug in Microchip's disgustingly
> messy and poorly implemented peripheral library.
>
> I2C_USE_RESERVED_ADDRESSES is a macro for 0x800, which corresponds to a
> logic 1 at bit 11 of the I2CxCON register. When set, strict reserved
> addressing is enforced and the device does not respond to reserved
> address space. Their library has it backwards.
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--=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
.