I2C addressing gap on 18F4680

[peter273]

Hi to all you guru's

After struggling for a couple of days to get I2C working between two 18F4680 I stumbled upon next item:
- When assigning a slave an address below or equal to 0x0e (= the "write to master address" being 0x0f) it will never respond to any masters request (ACK stays high)
- When assigning a slave an address from 0x10 up (= the "write to master address" being 0x11) it will respond to the masters request as defined in the datasheets and 2-way communication works like a charm(ACK nicely goes low as it should)

Anybody else ever noticed this ???

I'm using rather simple statements
#use I2C(MASTER, sda=PIN_C4,scl=PIN_C3, SLOW, FORCE_HW, STREAM=I2C_1)
and
#use I2C(SLAVE, sda=PIN_C4,scl=PIN_C3, address=0x10, FORCE_HW, STREAM=I2C_1)

and the well known (and overly-documented here )
i2c_read(I2C_1, 0x11) and i2c_write(I2C_1, 0x10) statements

Leaving "stream" and "FORCE_HW" out makes no difference at all, only setting the slaves address from 0x10 up (even addresses) gets things working as they should.

Anybody else ever noticed this ??
Or am I just trying something exotic again ?
(wouldn't be my first time )

It would be nice not to have an offset as large as 0x10 in addressing, especially when having a load of I2C slaves to address.
Seems also somewhat silly to have the physical "device_0" to have an address of (device_0 + 0x10) instead of (device_0 + 0x01)

As far as I interpret all the documentation the slave address 0x00 is reserved for a general call (I assume 0x01 being the "write to master" then), and all slave addresses from 0x02 up can be used as a valid slave address (the odd ones being "write to master").

I'm using the CCS PCH compiler 4.042

[Ttelmah]

Start with the 'bad news'. You have chosen on of a group of chips, that have more 'faults' with the MSSP module, than any other. If I remember correctly, currently over a dozen erratas for this module....
Change the way you think about IC addresses. I2C addresses are _seven bit_ values, sent in the high seven bits of the first byte (this is exactly how they are described in the I2C paperwork). There is no 'write to master' address, there is a single address, and then separately, the direction control bit. The seven bit address should be multiplied by 2, when given to the CCS instructions.
So, addresses are 0, to 127 only.
Now, on the 'GCA' address, if you don't want to use it for general addressing, disable this ability in the chip (clear GCEN, bit 7, SSPCON2). This then opens the full range of addresses.
On your problem, the chip should always ACK, _provided the buffer full bit is clear before the address is received_, and the chip is in the idle state. Make sure about this. Note that one of the erratas affects this. Also note that there is an erratum, saying that these chips will sometimes respond incorrectly to addresses (the other way round to what you are seeing, but possibly connected). It certainly suggests that these are not the chips to use if you want to put a lot of devices on the bus!. It might also be worth enabling the GCEN bit, if it is disabled, since on another chip in the same part of the family, there is an 'odd' behaviour, if this is not enabled...
What pull up value are you using. Odd addressing, can be a sign of slightly weak pull-ups..

Best Wishes

[peter273]

Ttelmah

Sorry for the expression "write to master", should indeed be "read from slave" in case of a set direction bit.
I'm well aware of the addressing of I2C modules, being (address<<1) for master-to slave and ((address<<1)+1) for slave-to-master.
The GCA is disabled, and pullups are 2k2 with (for the moment) 20cm signal path, and very well defined rise/fall times (<15ns falling edge, <80ns rising edge).
I'm also well aware of the erratas now, almost know them by heart since reading them over and over for say a week now to find what was going wrong .

But:
Without changing any code, only modifying slaves address from 0x0e (or below) to 0x10 (and above), gets all running as it should.
In no way I mask out any of the address bits in the code.
Setting the slave address equal or below 0x0e cripples communication, no ack is given any more despite correct presence of databits and clock.
I've tried address from 0x02 upto and including 0x0e, no avail.
I've then also tried several addresses from 0x10 up, they all worked fine.
This simply means my protocols/code do work two-way (echoed responses to hyperterminal by rs232 is correct), only the address range 0x02...0x0e fails in some weird way.
In not a single snippet of paper I have read on I2C this range is excluded or reserved.
Did anybody see this before or has an explanation for this odd kind of behaviour ??

[PCM programmer]

[peter273]

Jeeeses.....
Thanks PCM, there's something I indeed flagrantly missed
Guess I missed those few trees with the rest of the wood standing in the way