I2C Issue

I am having problems with my reverse which is "not found" when I call the GUI module with this error message - "Found device at 44 but it is not a picoborg reverse (ID 00 instead of 15)" then tries the other bus. Also the Ultraborg has the same issue in this case device found at 36 but id FF instead of 36. There is one other device on the i2c bus at 70 which is working normally. The host is a Pi 3.
Both boards have been working well until a few days ago when I started to get the vnc connection freezing after calling either board's GUI. The pi software has been updated recently which may be the root cause but I have also revised the interconnections. I have checked the wiring and it all seems correct and as the other device is working ok so wonder if this is Picoborg related and maybe the error means something to you.

piborg's picture

Well this is a bit of a strange problem, but it is something to do with the I2C bus one way or another.

What I would do is to try and simplify the problem.
What behaviour do you get with just the PicoBorg Reverse attached to the Pi 3?

Thanks for the quick response.
I get the same result when there is just the Reverse attached. The other device that was working normally is a relatively simple led unit (BrightPi). I have had all three working together so I guess the problem is software related rather than physical.

piborg's picture

I agree, it does sound like software is the more likely cause.

The error you are getting (wrong ID) seems to suggest that both boards are still talking and responding to their respective addresses.
If I had to guess the problem has something to do with getting replies from the boards, not sending them commands.

What do you get back if you run this command:
sudo i2cdetect -y 1

Sorry for the delay in responding - disconnecting was a lot easier than reconnecting!!. Same responses from Reverse and these are the result of the command:

pi@TankCam:~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77

Previously I would have just seen the three addresses listed

piborg's picture

There is definitely something wrong there, usually when we see that kind of error it points to a wiring issue.

Could you re-run the command with nothing at all connected to the GPIO pins?
If it stays the same then the problem is definitely Pi side.

The Pi is being powered by battery from a Battborg so cannot totally disconnect from the GPIO pins. However, I have rejigged it so that pins 1-6 are connected direct to the Battborg excluding the i2c boards. The scan result is the same.
Would it be worthwhile disabling i2c in the pi config and then after a start up and scan re-enabling it ?

piborg's picture

It could be worth trying, it does seem like the problem is somewhere with the Raspberry Pi.

If that does not work try the GPIO pin test from this post:
https://www.piborg.org/comment/5284#comment-5284

Right, disabling and re-enabling didn't work.
Have run the pintest as suggested and that gives me an error "pin 8 failure -expected 1 got 0" . I have uploaded a screenshot of gpio readall which shows pin 3 0 and pin 5 1 with both set to mode IN. Is this a software issue and if not is there a workaround?

Images: 
piborg's picture

All of the pins being set to IN after running the pintest is normal, a reboot should put the GPIO pins back to default modes.

The pin error is more worrying, it suggests that the GPIO pin used for the I2C data line is not working correctly.
I suspect that the BrightPi works because the code is only getting the Raspberry Pi to send data to the board, not read values back from it.

Given this half-working I2C it might be possible that it is a software issue, but it would seem more likely that the pin has become damaged in some way.

If you do not need to read values back from the PicoBorg Reverse you could try and get it to ignore the ID error and continue anyway.
This may allow you to control the motors still, or it might not work at all.

To try this open PicoBorgRev.py in a text editor like nano.
Look for the Init function:

    def Init(self, tryOtherBus = True):
        """
Init([tryOtherBus])

Prepare the I2C driver for talking to the PicoBorg Reverse
If tryOtherBus is True or omitted, this function will attempt to use the other bus if the PicoBorg Reverse devices can not be found on the current busNumber
        """
        self.Print('Loading PicoBorg Reverse on bus %d, address %02X' % (self.busNumber, self.i2cAddress))

        # Open the bus
        self.bus = smbus.SMBus(self.busNumber)

        # Check for PicoBorg Reverse
        try:
            i2cRecv = self.bus.read_i2c_block_data(self.i2cAddress, COMMAND_GET_ID, I2C_MAX_LEN)
            if len(i2cRecv) == I2C_MAX_LEN:
                if i2cRecv[1] == I2C_ID_PICOBORG_REV:
                    self.foundChip = True
                    self.Print('Found PicoBorg Reverse at %02X' % (self.i2cAddress))
                else:
                    self.foundChip = False
                    self.Print('Found a device at %02X, but it is not a PicoBorg Reverse (ID %02X instead of %02X)' % (self.i2cAddress, i2cRecv[1], I2C_ID_PICOBORG_REV))
            else:
                self.foundChip = False
                self.Print('Missing PicoBorg Reverse at %02X' % (self.i2cAddress))
        except KeyboardInterrupt:
            raise
        except:
            self.foundChip = False
            self.Print('Missing PicoBorg Reverse at %02X' % (self.i2cAddress))

        # See if we are missing chips
        if not self.foundChip:
            self.Print('PicoBorg Reverse was not found')
            if tryOtherBus:
                if self.busNumber == 1:
                    self.busNumber = 0
                else:
                    self.busNumber = 1
                self.Print('Trying bus %d instead' % (self.busNumber))
                self.Init(False)
            else:
                self.Print('Are you sure your PicoBorg Reverse is properly attached, the correct address is used, and the I2C drivers are running?')
                self.bus = None
        else:
            self.Print('PicoBorg Reverse loaded on bus %d' % (self.busNumber))

Change foundChip to be True above the error you are seeing:

                    self.foundChip = True
                    self.Print('Found a device at %02X, but it is not a PicoBorg Reverse (ID %02X instead of %02X)' % (self.i2cAddress, i2cRecv[1], I2C_ID_PICOBORG_REV))

If you now try and use the GUI it should still display the error, but continue anyway.
If the I2C sending still works you should then be able to control the motor outputs.

Thanks, I'll give it a go over the weekend. I guess that although a similar 'fix' to the Ultaborg code would allow the servos attached to it to work the Ultrasonic sensors won't.

piborg's picture

That is right, the servos should still work with the same alteration, but the ultrasonics will probably just come back with a reading of 0 constantly.

Having thought about it further I think the issue may have arisen with the complexity of wiring that may have resulted in a 5v being connected very briefly to the i2c pin or one of the boards has touched it being supported in one corner only. My plan is to source a new pi3 plus an expansion board https://www.modmypi.com/raspberry-pi/breakout-boards/modmypi/modmypi-mcp... which should allow me to connect the 5v sensor inputs and other gpio conenctions to the expansion board which will isolate them from the Rpi pins whilst the extended header will allow the Picoborg Reverse and Ultraborg boards to be connected with the battborg providing the 5v power via one of them. The retired Rpi will be used as a cctv camera which doesn't require i2c.

Thanks for your help in diagnosing the problem and the workaround.

Subscribe to Comments for "I2C Issue"