Reference : TCA9539 datasheet (SCPS202C Oct 2009 - Revised May 2016)
Assumptions: Lets assume that one I/O expander is used for outputs and the other used for Inputs.
question 1) Is the repeated start for a read required?
First this device on page 24 (section 8.6.3.1.2)regarding reading from the expander - the datasheet shows a repeated start, is this required, as the drivers we have do not support this. Also on page 21 (section 8.6.2) the wording says "When a command byte has been sent, the register pair that was addressed continues to be accessed by reads until a new command byte has been sent. " So am i reading this wrong but this seems to indicate that i can dd the expander read in 2 steps - the first step being the transaction :
step 1 ) Start <dev slave addr (wr)> Ack <reg address to read from> ACK STOP
step 2) Start <dev slave addr (rd)> Ack <data from slave> NAk Stop.
But i dont know if this would work although as mentioned the datasheet seems to indicate that when a command byte (reg address to read from) is sent the register continues to be accessed by reads until a new command byte if sent. So I dont know if i really need to do this repeated start or if im good breaking it up into 2 steps as shown.
Just to be clear this is what im talking about - it looks like it is working but is there any problems of doing things this manner
Obviously it would be better to have it all one transaction so that another master couldnt take over the bus mid-tranaction, but besides this - is there any problem with the 2 step read?
question 2) What might be causes of spikes on the SDA line, as during the I2C transaction we are seeing spikes with are effecting data integrity, we have tried lowering the resistor values thinking the issue may be due to capacitance loading but this has proven to not be the case, although we are now using 4.7K pullups.. I have attached several pictures - any suggestions would be appreciated, as to what might be causing this.
The communication medium is via SW to a xilinx processing system
Its seems that the output data is sometimes corrupted. One of the ports seems to always be reliable but we see spikes that are interfering with data sent to the device