5
\$\begingroup\$

I'm using a single PIC16F18857 as an I2C master to talk to five PIC16F1615's on the bus. All is working great, for the most part, however, I've been experiencing a "lock up" where the master is stuck in a loop waiting for a read to complete. I managed to catch it on the analyzer and here's what I'm seeing:

i2c signals

The third signal is an async UART input to the master PIC16, I was trying to see if the timing of it with relation to the was somehow related, but I've seen nothing to support that so far.

There are currently only two slaves on the bus, and the read always fails during the read to the first slave.

What's curious to me is that the master (which is controlling the clock) seems to stop clocking the slave after three clock cycles (I'm seeing three cycles consistently) and I'm missing an interrupt -- most likely because the clock sequence is not finishing all of its cycles. I would be less puzzled if the clock was being held low by something, but it seems the clock is stuck in the "unasserted" high state.

Under what circumstances may this happen?

  • I have checked the silicon errata for both parts, nothing that pertains to this issue is listed for either part
  • I've tried to see if its correlated with another peripheral interrupt firing, none of the data I've collected seems to point to that being an issue

Thanks!

\$\endgroup\$
2
  • 1
    \$\begingroup\$ (a) "currently only two slaves on the bus" I hope you've suitable pull-up resistors too? (b) "read always fails during the read to the first slave" From experience, I'm cautious about taking that at face value. Unless you treat both slaves equally at all times (e.g. which you read "first" in any sequence etc.) then it's easy to be misled by a problem which could affect all slaves, but seems to affect only 1 slave due to ordering of reads etc. (c) I would use a 'scope to view a "failed" I2C transfer - just because the analyser shows SCL "high" does not necessarily mean this is true. \$\endgroup\$
    – SamGibson ♦
    Commented Jan 9, 2018 at 4:48
  • \$\begingroup\$ (d) If "read always fails during the read to the first slave" is valid for comparing the two slaves (e.g. equal number of reads attempted to each slave "first" etc.) then failures only on reads to 1st slave might be telling you something. Compare the two slaves, finding differences (since if there was no difference, h/w or s/w, then you'd get the same behaviour!). Example - there must be a physical difference e.g. different places on I2C bus, for example. Personally I'd use Kepner-Tregoe PSDM "problem analysis" techniques e.g. the IS/IS NOT pairs (I'm not affiliated, just a happy user). \$\endgroup\$
    – SamGibson ♦
    Commented Jan 9, 2018 at 4:57

1 Answer 1

Reset to default
1
\$\begingroup\$

Do you do any I/O outside of interrupts, like lighting an LED after getting the first byte? A read-modify-write could end up setting the port bit by accident. One thing you can do is read the direction register and the port data to see if they are still in their expected state. Another way to make I2C go away is to disable the port, so read the register that has the i2c-enable bit and check that it's still enabled.

Long shot better than no shot.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.