This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCA9535 registers seem to change due to reads

Other Parts Discussed in Thread: TCA9535

I am running a TCA9535 from a Pyboard (see I can talk to the 9535, all the levels look good on a scope (running at 3.3V). I monitor the I2C with a Jupiter Instruments I2C monitor, and see transactions in the order I expect. Here is the odd thing- when I change a bit on output port 0, and do it again, other registers in the 9535 appear to have changed. The log below shows the situation. First pass through, bit 0 is set, and then the registers are read back; second pass through bit 0 is cleared and then the registers are read back. Nothing in between. As can be seen, the registers read out differently on the second pass.

Micropython's I2C module seems to do reads by first doing a write with a register address, then a repeated start, and then a read.  Unless the 9535 doesn't like repeated starts for some reason? This was at 100kHz, I tried it at 20kHz, and the results were the same. So everything is clean, repeatable, but wrong!

First pass through

Msg 001 <Start>[Add:40(W)]<ACK>[#02]<ACK>[#01]<ACK><Stop> t=287us <Set bit 0
Msg 002 <Start>[Add:40(W)]<ACK>[#06]<ACK> t=196us
Msg 003 <Start>[Add:41(R)]<ACK>[#F0]<NACK><Stop> t=196us <Correct
Msg 004 <Start>[Add:40(W)]<ACK>[#07]<ACK> t=196us
Msg 005 <Start>[Add:41(R)]<ACK>[#00]<NACK><Stop> t=196us <Correct
Msg 006 <Start>[Add:40(W)]<ACK>[#00]<ACK> t=196us
Msg 007 <Start>[Add:41(R)]<ACK>[#F1]<NACK><Stop> t=196us <Correct
Msg 008 <Start>[Add:40(W)]<ACK>[#01]<ACK> t=196us
Msg 009 <Start>[Add:41(R)]<ACK>[#FF]<NACK><Stop> t=196us <Correct
Msg 010 <Start>[Add:40(W)]<ACK>[#02]<ACK> t=196us
Msg 011 <Start>[Add:41(R)]<ACK>[#01]<NACK><Stop> t=197us
Msg 012 <Start>[Add:40(W)]<ACK>[#03]<ACK> t=196us
Msg 013 <Start>[Add:41(R)]<ACK>[#FF]<NACK><Stop> t=197us

Second pass through

Msg 014 <Start>[Add:40(W)]<ACK>[#02]<ACK>[#00]<ACK><Stop> t=287us <Clear bit 0
Msg 015 <Start>[Add:40(W)]<ACK>[#06]<ACK> t=196us
Msg 016 <Start>[Add:41(R)]<ACK>[#FF]<NACK><Stop> t=197us <Changed
Msg 017 <Start>[Add:40(W)]<ACK>[#07]<ACK> t=200us
Msg 018 <Start>[Add:41(R)]<ACK>[#FF]<NACK><Stop> t=196us <Changed
Msg 019 <Start>[Add:40(W)]<ACK>[#00]<ACK> t=196us
Msg 020 <Start>[Add:41(R)]<ACK>[#F0]<NACK><Stop> t=197us <Changed
Msg 021 <Start>[Add:40(W)]<ACK>[#01]<ACK> t=196us
Msg 022 <Start>[Add:41(R)]<ACK>[#00]<NACK><Stop> t=196us <Changed
Msg 023 <Start>[Add:40(W)]<ACK>[#02]<ACK> t=196us
Msg 024 <Start>[Add:41(R)]<ACK>[#00]<NACK><Stop> t=197us
Msg 025 <Start>[Add:40(W)]<ACK>[#03]<ACK> t=196us
Msg 026 <Start>[Add:41(R)]<ACK>[#FF]<NACK><Stop> t=197us

  • Gordon,
    We are looking at your question and will get back to you.

  • Gordon,
    From the code it seems like the TCA9535 is resetting back to default register values after you clear the register 0x02 bit 0. Can you check the power-on-reset status? is the VCC maintained or does it go below the power on reset threshold?

  • Rajan,

    No, the supply is 3.3V, and I can't see any variation on a scope- I triggered on the I2C data. It is supplied by a linear regulator, and there is a 100nF right next to pin 21.

    One other thing- once it gets into what looks like the reset condition, I find I have to power it down to get it to set up correctly again. It seems to be "locked up", as it were. The pin that I am toggling is driving a 10K resistor, so there should not be much current.

    I used a second I2C analyzer, just as a check, but it reports the same message sequence exactly.

    It is definitely when I write to P0.1 that the problem occurs- I can do the rest of the read statements many times with no problems. But as soon as the bit is toggled, the problem happens.

  • Rajan,

    I finally got it! You were correct, the supply was collapsing, but not during the I2C transactions. That is why I never saw it. I zoomed my scope out, and it soon became obvious. The problem turned out to be a floating input in another part of the circuit, and so I never suspected it at first.

    Thanks for your help. The part appears to be working normally for now- I consider this issue to be closed.

  • Gordon,
    Glad to help!