XC161CJ and I2C

Hello Barry,

Why does an extra read operation fix things up?

This is a good question and I agree that it would be indeed more helpfull to know the root problem, but I do not know about any problems in the HW-modul as far as concerning XC166 family.
As I found the DAvE bugs and that we need some times a dummy read I contacted the Infineon guys for this stuff.
They gave me the low level driver and told me....
( sorry for some mistakes in following translation )

" ...that an extra read is not so unusual, if one is looking to the I2C protocoll.
One will see that only the master suplies the bus with a clock signal.
If one is setting the slave into the read mode, this does not mean that at same moment
valid datas are in the receive buffer.
It (the slave) can only write datas onto the bus, if it get a clock from the master.
That is why we need the dummy-read, to read after that the first valid data from the buffer." .... 

Hello Barry,

Why does an extra read operation fix things up?

This is a good question and I agree that it would be indeed more helpfull to know the root problem, but I do not know about any problems in the HW-modul as far as concerning XC166 family.
As I found the DAvE bugs and that we need some times a dummy read I contacted the Infineon guys for this stuff.
They gave me the low level driver and told me....
( sorry for some mistakes in following translation )

" ...that an extra read is not so unusual, if one is looking to the I2C protocoll.
One will see that only the master suplies the bus with a clock signal.
If one is setting the slave into the read mode, this does not mean that at same moment
valid datas are in the receive buffer.
It (the slave) can only write datas onto the bus, if it get a clock from the master.
That is why we need the dummy-read, to read after that the first valid data from the buffer." .... 

Hello Stefan,
Thanks for your informative post. Again I've just been working with SMB and don't know I2C at all but I've read they're quite similiar. At first I was confused by the 28 different sources for the interrupt vector but after sorting things out two things were apparent. The fardware modules have a state machine which manages the idle-address-data transfer-idle changes and that the ACK/NACK at the end of each transfer drove the interrupt requests. The most time critical part of the code was during a master read of a slave. You're right the master generates the clock and the slave hardware module shifts out whatever happens to be in the buffer at the time, so the slave had to have data ready in the buffer when the shifting starts! I rolled my own handler which uses dynamically sized packets, a dedicated isr packet buffer, and input and output circular buffers with interrupt protected read and write functions. NACK response includes a retry scheme with timeout error handler, this tolerates delay due to interrupt activity in the receiver module. It's set up for a multimaster connection and I'm still working on the arbitration scheme.
Cheers,
Barry