I’m debugging an i2c bus for a project at the moment and I am experiencing some behaviour that I cannot explain. Any advice or explanations are welcome.
The problem is that my i2c subroutine is written to send bytes in 400u - 500u seconds but in this case I am not seeing that on the oscilloscope.
What I am seeing is the first byte (address byte) sent in under 500u seconds and the second byte (data) being transmitted directly after the address over 1250u seconds. The same subroutine is used for both transmissions, so what causes the second byte to be stretched so far?
The weirdest part is that when I put the command CALL SENDVAL in-between loading the second byte and sending the second byte the stretching doesn’t happen.
I am transmitting to an NXP PCF 8574 and a TI DAC 8574.
The code used for this procedure is attached in .asm file.
Also I forgot to mention, the most serious part of this problem is that if I leave the CALL SENDVAL command out the actual value sent by the i2c master is changed and does not coincide with what was loaded into the register for sending it.
It is meant to send the byte 00000000 but instead it sends 10010000
Thanks for all the replies,
I solved the problem, one of the subroutines that was used just before the i2c transmission had a CALL ES in it which enables serial interrupts. The interrupts then caused interference with my i2c bit bang process.
CALL ES removed, errors are now gone.
The stretching problem is still evident and I have been looking up i2c stretching and I don’t see how it could be meant to happen because the stretching takes so long ie. 100s uSeconds