General Call Problem with I2C Slave code within PIC16F1936

[Steve Smith]

I have a problem with General Call in my I2C slave code. I hope that someone can help.
I have copied the format of the pksa.c file in the Microchip website. The main difference is that my code is within an ISR. I have four states which are derived from masking SSPSTAT for relevant bits.
Everything seems to work fine until I address my slave with General Call.
Then things go a bit strange.

If the previous command to my slave was purely writing data from the Master, then the General Call works absolutely fine.
However, if the previous command to my slave includes the Master reading data from the slave (which also works fine), the General Call goes 'screwy' after this point.
My slave always generates an ACK (addr match), but the R/W bit is set! This bit stays set for every subsequent data byte written from Master to Slave. As my states are expecting the R/W bit to be clear when writing data in to slave, the data is being lost!

This happens 100% of the time. The only way I can use General Call to write commands in to the slave, is to precede the General Call with a 'Unique I2C Address match' command containing purely write bit set data.
After which General Call works again.

I currently only use General call to change the unique I2C Address of the Slave.

CCS Compiler Version 4.119. PIC16F1936.

[Ttelmah]

I don't think a GCA, with 1 in the low bit is legal.
GCA, is a broadcast from the master to all slaves on the bus. The I2C documentation only shows this with a 0 in the low bit. How can you broadcast to everyone, then have a reply?. After all every device on the bus would reply to this?.
You can set an address inside GCA, and then address a specific slave, and have this reply, but a 'general call', with all devices replying, would break the bus....

Best Wishes

[Steve Smith]

Firstly, thank you for looking at my issue and replying so quickly.
I agree, a GCA with a 1 in the R/W bit is illegal. Also, if I tried to do this, all slaves would talk at once. However, this is what the PIC is generating within SSPSTAT register. I can not control it. This is the problem I have.

When I carry out a General Call, all I wish to do is to write a command and data to the slave, and because of this I would expect the R/W bit to be 0 (write). I do not ever try to read data from the slave under General Call.
The R/W bit seems to be set to a 1 by the PIC during a General Call, ONLY if the previous communications between Master and Slave included the Master reading data from the Slave. If the previous communcation was the Master purely writing to the Slave, then the next General Call works absolutely fine.

Regards

[Steve Smith]

Just to clarify, when I talk about 'previous communications between Master and Slave' and 'Everything else seems to work fine', I am referring to addressing the Slave with its unique address.
The only issue I seem to be getting, is when I try to send a command and data to the slave under General Call after I have read data from slave addressing it with its unique address value.


Sorry for any confusion.

Regards

[Ttelmah]

So are you following the full CGA standard?. Send the GCA, followed by '4', or '6' (the former says 'set the settable part of the address', while the latter says 'reset, and set this address'. The slave device to a GCA, is _required_ to ACK the bus, and wait for the second byte. A GCA, is not complete, till the second byte is sent. This is then followed by the 'programming sequence' (which you will have to define), designed to send the addresses in such a way that chips will each get a unique address.

Best Wishes

[Steve Smith]

Thanks again. I will look at the spec more closely for General Call.

However, if I pause my code (running in MPLAB Debugger) straight after I send Start then 00 (general call), the R/W bit in SSPSTAT is still a 1. Surely this bit should be a 0?

Regards