• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 145 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

PCA9545A: Mastering I2C/SMBUS from downstream of switch

Andrew Bond
Prodigy 10 points
Part Number: PCA9545A

Tool/software:

Hi,

I'm trying to get some external telemetry from a motherboard by using an Aardvark I2C controller to master the SMBUS via test pins and communicate with an RT3674AE regulator. Through trial and error, I believe the bus topology looks like this:

[CPU] ---- [ i2c controller ] ---- [  PCA9545A 3] ---- [RT3674AE] ------[other devices]
                                   [           2] ---- [Test pins] ---- [Aardvark]
                                   [(disabled) 1] ----
                                   [           0] ----

When I use a Linux shell to communicate with the RT3674AE (from upstream of the switch), I get expected values. When I use the Aardvark (downstream of the switch), I can read and write some registers like chip id and page, but any time I try to read the voltage I get a value that doesn't make sense, and is different from what I get using a Linux shell. I have probed the bus with i2cdetect and I don't think there's an address conflict, though I can't be certain. 

I asked the same question on stack exchange here (https://electronics.stackexchange.com/questions/720343/i2c-regulator-returns-different-values-upstream-and-downstream-of-switch?noredirect=1#comment1916321_720343) and a responder said it was improper to master the bus from downstream of the switch.

Is it indeed the case that I should not expect valid values if I'm mastering the bus from downstream of the PCA9545A?

Thanks.

  • 0
    TI__Mastermind 26868 points

    Hey Andrew,

    If I'm understanding your intended use, the stack exchange user is correct here. The PCA9545A SCLx/SDAx pins are only going to be for downstream devices and can't be used as the controller input. If the controller is on the target side you'll have problems enabling/disabling and likely some other communication glitches. So if you select the aardvark (channel 2 from your diagram) the aardvark and i2c controller can communicate fine, but if you wanted to actually control via the aardvark you won't be able too.

    You could try using a passive mux and toggle the paths using GPIO's as simple solution, if you have the GPIO's to implement. Something simple like a SN74LVC4052A could be used. 

    Thanks,
    Rami

  • 0 in reply to Rami Mooti1
    Prodigy 10 points

    Thanks for the reply, Rami. What causes these communication glitches? The block diagram in the PCA9545A's data sheet implies that when multiple channels are enabled, it's all one bus and a controller could be anywhere in the tree. And the glitches seem to just be particular registers on the RT3674A; I can reliably get some other registers and even control the switch, though I don't need to for my application.

  • 0 in reply to Andrew Bond
    Guru 271300 points

    Getting glitches one some registers sounds like an address conflict. The only way to confirm this would be to disable channel 3 and test the address.

  • 0 in reply to Andrew Bond
    TI__Mastermind 26868 points

    Hey Andrew,

    I'd agree with Clemens here, this sounds like some address conflict.
    That being said just to expand on my previous comment and the comment on the user from the stack exchange, you should be able to communicate upstream but the real issue is that the main SDA/SCL is connected to the internal state machine of the PCA device. So eventually if you try to use the upstream device as the controller and say switch the PCA configuration, you'd likely lock yourself out. Which is why I was recommending possibly using a GPIO controlled mux instead.

    Thanks,
    Rami