Dave has developed a hardware issue that prevents him from “knowing he is still alive”.
Dave depends on an I2C sensor to know when he is charging or discharging, and yesterday his I2C bus suddenly stopped detecting any devices on the bus, not the GoPiGo3 red board and not the current/voltage sensor plugged into the GoPiGo3 board.
Carl uses extensive voltage pattern matching to recognize his charging state, but uses the DI I2C distance sensor to know how far he has to back to get on his dock.
Both robots’ “lives” depend on correctly functioning I2C, with no failure tolerance and fallback operation.
I’m going to have strip Dave down to his underwear to figure out if the I2C bus 1 is blown on the Pi5 or the GoPiGo3 redboard. I can reprogram Dave to live without I2C, but it is not the desired operational condition.
I ran into the same thing with Charlie, (?), where one of the SPI channels on the GPG controller is having problems, though I might be able to solve it with a pull-up resistor.
You have a 'scope, right? I’d monitor the i2c buss and make sure you’re getting the full voltage swing, zero to at least three volts. If not, you can try a soft pull-up to see if you can pull it high when the bottom leg of the MOSFET output gate shuts off. (I’m going to try that on Charlie too starting with a 20k resistor, then trying 10k, then 5k but I won’t go below that.
If the line is stuck high, I’m not sure how to fix that. A pull-down maybe? Charlie’s SPI channel isn’t pulling high with a display board plugged in - I don’t know why, and it’s true for every SPI-based display I have. (I need to buy a new one to test with.)
Since it doesn’t pull all the way high, I might be able to get it to pull high with a soft pull-up - the softer the better. . .
Before you take Dave to bits, try probing with a 'scope first.
yeah, i checked the GoPiGo3 connectors 5v on vcc and 3.85v on SCL and SCA. next I’m going to ground SCA and see if all/any I2C addresses show occupied. Should be all.
I hope to be able to get a probe on the 40 pin SCA to see if the level shifters are working. If yes, pi5 bad I2C. If no, bad GoPiGo3 level shifters.
Either way, Dave can limp along but want to understand what to replace in time.
Don’t even think of that unless you want to blow the output if it tries to drive high!
A dead-short to ground is exactly what you don’t want to do with a pin that’s being actively driven.
In my case where I use grounding dip-switches, I use the last six or so pins that I’m almost certain are never used - at least not by the GoPiGo.
If I was smart, I would create a circuit that would allow the selected pin to be grounded if, and only if, PI RUNNING isn’t high. When it goes high those pins should tri-state. (go to a high-impedance state)
The “master” device, (the Raspberry Pi) asserts the line and sends out the first i2c address with an “ATTENTION/STATUS” command and then waits for a response.
If it gets one, it fills in the blank with the address
If there’s an installed device tree overlay for the device at the address, it fills in “UU” instead.
if not, leaves it blank.
It then increments the i2c address and does it all over again until it runs out of addresses.
Communication between i2c devices is the same way, the master sends out an address and a special command frame to get the device’s attention. Once it gets an “ACK” frame in return, it sends out a command followed by data if necessary. So long as the remote device keeps responding appropriately, everything’s cool. Otherwise you get an i2c error and maybe a hung system.
Well I thought about it, and with your wise admonition looked at the GoPiGo3 schematic and found the pull up is 12.5K ohms so I rummaged through my junk and found a 2.2k ohm to ground SDA with.
I ran gpio readall with SDA floating, it showed “1” on both SDA.0 and SDA.1. Next put the 2.2kohm between the GND and SDA on a GoPiGo3 sensor cable plugged into one of the two I2C GoPiGo3 sockets, and checked gpio readall again. Still “1” -
Doesn’t tell me squat about whether it is the redboard or the Pi5 but ain’t nothing getting to or into the Pi5 on the I2C data line. I don’t have a spare Pi5 to test with, so Dave is going to have to revert to a Pi4 and run GoPiGo OS to differentiate the problem is Pi5 or the problem is the redboard.
That’s only safe if you have a LED in series with it.
I wouldn’t use less than 5k on a line I know is being driven as the GPIO pins are driven directly by the main processor and they don’t appear to be buffered for anything more than a few ma. (The various books I’ve read say that driving an LED directly is too much current and you’ll blow an output.
These pins really need to be buffered to at least 500ma on the die, but they didn’t.