T
Tony Mountifield
- Jan 1, 1970
- 0
While I'm waiting for an answer from Cirrus, I thought I'd ask here...
I'm investigating I2C problems with controlling a CS4931 audio DAC in
an existing design that is about 3 years old.
The I2C bus is driven by software controlling port lines. There are other
devices on the bus, but they are not in use at the time of the problem.
The problem is that sometimes the I2C slave will send the ACK bit after
the master has sent only 7 bits instead of 8. So the ACK is asserted over
the top of the 8th bit, and then when the master is looking for the
ACK it has already been and gone, and who knows what value the slave
thinks it has been given?
This happens at random on either the address byte or one of the data bytes.
It seems to be a tolerance thing, since some units do it occasionally and
others do it frequently.
The timings of the start, stop and bit clocks are all correct, and verified
using an I2C-aware DSS. The I2C bus looks clean, both at the master and
slave ends. So I'm pretty confident we are not doing anything to provoke
the error. We suspect the problem has always been there to some degree,
rather than been introduced recently.
Has anyone seen this kind of problem before? Any specific experience with
I2C on this chip?
Thanks in advance for any suggestions!
Cheers
Tony
I'm investigating I2C problems with controlling a CS4931 audio DAC in
an existing design that is about 3 years old.
The I2C bus is driven by software controlling port lines. There are other
devices on the bus, but they are not in use at the time of the problem.
The problem is that sometimes the I2C slave will send the ACK bit after
the master has sent only 7 bits instead of 8. So the ACK is asserted over
the top of the 8th bit, and then when the master is looking for the
ACK it has already been and gone, and who knows what value the slave
thinks it has been given?
This happens at random on either the address byte or one of the data bytes.
It seems to be a tolerance thing, since some units do it occasionally and
others do it frequently.
The timings of the start, stop and bit clocks are all correct, and verified
using an I2C-aware DSS. The I2C bus looks clean, both at the master and
slave ends. So I'm pretty confident we are not doing anything to provoke
the error. We suspect the problem has always been there to some degree,
rather than been introduced recently.
Has anyone seen this kind of problem before? Any specific experience with
I2C on this chip?
Thanks in advance for any suggestions!
Cheers
Tony
