0
\$\begingroup\$

I am implementing PMBus (variation of SMBus and I2C) communication using a Raspberry Pi 4B+ (RPi) as the master. I am having issues with the slave power supply (PSU) irregularly answering the acknowledge bit of a simple I2C scan using the i2cdetect command.

My setup: I am using a P82B96 chip to isolate both I2C bus sides. The RPi side is 3.3 V and the slave side is 5 V.

What I tried :

  • Plugging another I2C device in parallel with the power supply. That device is recognized as expected.
  • Lowering the frequency of the bus. The PSU is stated for 100 kHz maximum on this bus. I tried frequencies ranging from 10 kHz to 400 kHz. I actually have a strange thing happening at high frequencies (400 kHz): The slave is recognized but it's impossible to communicate with it. I am assuming it's a bug.
  • Changing from hardware I2C to software I2C ports on the Raspberry Pi side. Pulled up with 1.8 kΩ to 3.3 V.
  • Changing the address of the PSU.
  • Swapping the RPi for a new one, swapping out the PSU.
  • Rebuilding the cables I made.

Here are two oscilloscope pictures of the bus when the slaves acknowledges and doesn't :

slaves acknowledges

slaves doesn't acknowledge

Here's also a picture of the terminal running the scans. Nothing has changed between the 2 scans and they are time spaced by probably 5 seconds. You can see my dummy I2C device at the address 5a.

terminal running the scans

After doing research this doesn't sound like a common issue. It would be nice if anyone has suggestions on this issue.

Edit: Schematic

schematic

\$\endgroup\$
5
  • \$\begingroup\$ Show the schematics. There are some weird middle-level waveforms on the bus. Also, exceeding 100 kHz and encountering weird behaviour is not a bug; you are exceeding 100 kHz and the device is rated to 100 kHz; expect weird behaviour. Also what protocol the power supply uses? You do know that i2cdetect uses a protocol that may not work with all chips? \$\endgroup\$
    – Justme
    May 31, 2023 at 5:26
  • \$\begingroup\$ It could be that P82B96 is also cause. Maybe bus is too long or noisy. Or it's the weird bidirectional buffering it does, as seen by the weird voltage levels. If there are other I2C buffers or risetime accelerators on bus, they may be incompatible. Simplify your system, make it work without any extra chips and tricks, such as without P82B96. \$\endgroup\$
    – Justme
    May 31, 2023 at 5:37
  • \$\begingroup\$ The power supply is compliant with PMBus Rev 1.1 which relies on SMBus. I implemented the PMBus protocol from an online library but could not communicate with the PSU so I worked back from there trying to make i2cdetect work. I'll try back without the P82B96 following your advise. I was getting weird behaviour before with the Rpi GPIOs being 3.3V and the PSU unit 5V. \$\endgroup\$
    – Lucas J
    May 31, 2023 at 5:56
  • \$\begingroup\$ Yes a 3.3V MCU can't be connected to 5V bus. Since you already did, make sure that nothing is damaged. \$\endgroup\$
    – Justme
    May 31, 2023 at 6:16
  • \$\begingroup\$ Please measure the waveforms at the PSU. \$\endgroup\$
    – CL.
    May 31, 2023 at 8:39

2 Answers 2

0
\$\begingroup\$

According to the second scope display, your target device is violating the I2C specification. The spec requires the SDA be stable before the rising edge of SCL and remain stable until the falling edge as shown in this diagram: enter image description here (Extracted from the I2C spec here.)

Your traces show SDA low before the rising edge of SCL (indicating an ACK) but it rises well before the falling edge of SCL.

Either your PS is violating the I2C spec (unlikely) or your wiring is such that it thinks it saw the SCL falling edge when it really didn't.

Please add schematics. Also , you say that you are using a cable to connect to the PS; what kind of cable and how long? I2C is not really designed to go over cables.

\$\endgroup\$
2
  • \$\begingroup\$ The OP is using P82B96, that can extend 250 meters, and is only I2C compatible, not compliant, and it uses internally multiple voltage levels for logic low level to check which side is pulling low and which side should be pulled low. \$\endgroup\$
    – Justme
    May 31, 2023 at 5:49
  • \$\begingroup\$ Added basic schematics. Interface on the PSU side is an RJ45 port. I tried a shielded Cat6a Ethernet cable and also a stripped Ethernet cable wrapping the clock signal with ground and separate wire SDA. Both have the same behaviour. Cable is 10cm long. \$\endgroup\$
    – Lucas J
    May 31, 2023 at 5:53
0
\$\begingroup\$

Thanks for your help on the matter. After changing my setup and testing few different things I achieved communication with the power supplies.

I firstly tried swapping out the Rpi for an Arduino Mega board. The logic level voltage of the Arduino is 5V so it could be hooked directly to the PSU bus port with no isolator. I achieved communication and control using the Wire.h library.

Going back to the Rpi I tried using a cheap logic level converter module for Arduino. 3.3V - 5V Logic Level Converter

Communication was still not working. Keep pushing I tried to implement a python code and restarted my system few times during this step. I realized i2cdetect was actually disturbing the system somehow. I don't have the logical explanation behind this behaviour but communication is now working through python as long as i2cdetect is not used beforehand.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Like I said, i2cdetect may not work with all chips. Depending on what protocol your power supply wants to communicate, it usually just don't detect chips, but if it simply makes the chip go into a non-working state, we'd need to see what exactly there is on the bus and you need to provide protocol specs of the supply. \$\endgroup\$
    – Justme
    Jun 7, 2023 at 5:43

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.