0
\$\begingroup\$

I'm trying to use an Aardvark I2C controller over the SMBUS_TEST1 header on an ASRock IMB-A8000 motherboard to read voltage and current from an RT3674AE regulator. I don't have a schematic for the motherboard, but through trial and error I've determined that there's a PCA9545A switch on the bus, with the CPU on one side, and both the RT3674AE and the SMBUS_TEST1 header pins on the other.

[CPU] ---- [ i2c controller ] ---- [  PCA9545A 3] ---- [RT3674AE] ------- [others]
                                   [           2] ---- [SMBUS_TEST1] ---- [Aardvark]
                                   [(disabled) 1] ----
                                   [           0] ----

The RT3674A is at address 0x20. I can get the chip id (register 0xfb, value 0x74) from both sides of the switch, using a Linux shell on one side of the switch, and Python to drive the Aardvark on the other.

The problem is when I try to read the two voltage registers at 0x8b and 0x8c, usually after writing to set the page but not always, I get two completely different values; the one I get from the Linux shell makes sense, but the one I get from the Aardvark doesn't. I've attached some screen shots of the transactions from both sides. I thought it may be an address conflict but as far as I can tell from using i2cdetect there are no other slave devices with address 0x20.

Has anyone seen anything like this before? Another thought I had was maybe there's a multi-master issue, but I only see traffic on the I2C bus at boot, and never when I'm trying to query the regulator.

Attached are some waveforms of both controllers initiating reads, captured parallel to the Aardvark and the SMBUS_TEST1 header.

Any help or insight is much appreciated. Thanks.

Aardvark reading chipid Aardvark reading chipid

Linux reading chipid Linux reading chipid

Aardvark writing page 0x3 (rail A) Aardvark writing page

Linux writing page 0x3 (rail A) Linux writing page

Aardvark reading voltage high byte Aardvark reading voltage high byte

Linux reading voltage high byte Linux reading voltage high byte

Aardvark reading voltage low byte Aardvark reading voltage low byte

Linux reading voltage low byte Linux reading voltage low byte

\$\endgroup\$
6
  • 1
    \$\begingroup\$ The PCA9545A is a mux, meaning that the only proper / reliable way to access downstream devices is from the upstream port, and while maintaining the mux's state (i.e: which downstream channels are active). From reading the datasheet, there is no promise that initiators on downstream channels may access devices on other channels correctly. Trying to control the PCA9545A from a downstream port will permit cutting yourself off at best. \$\endgroup\$
    – Attie
    Commented Jul 23 at 21:22
  • \$\begingroup\$ Where in the tree did you capture the signals you've shared? \$\endgroup\$
    – Attie
    Commented Jul 23 at 21:24
  • \$\begingroup\$ Thanks Attie, that would certainly track with what I'm seeing. But it's so enticing to be able to get reliable one register reads on the RT3674AE from downstream. I've also been able to query and control the PCA9545A from downstream, though obviously as you say this just serves to cut the SMBUS_TEST header from the rest of the bus. \$\endgroup\$
    – olishmollie
    Commented Jul 24 at 13:44
  • \$\begingroup\$ Those signals were captured downstream from the PCA9545A on the SMBUS_TEST header, parallel to the Aardvark. \$\endgroup\$
    – olishmollie
    Commented Jul 24 at 13:45
  • \$\begingroup\$ Hey @Attie, I was just taking a closer look at the waveforms, and I noticed that every Aardvark transaction has a distinct pulse between the repeated start and the read address. Could that be a sign that there's another slave responding on the bus? \$\endgroup\$
    – olishmollie
    Commented Jul 24 at 16:01

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.