Strange behavior when controlling GPIOs

[ahrastnik]

Toggling or setting high as inputs, GPIOs 13 & 6 - which correspond to Cliff sensor inputs - result in RPi turning off WiFi, turning on the hot-spot or even powering off.

Tested GPIO libraries

This behavior was observed with pigpio & wiringpi libraries. Therefore, the initial conclusion is it's not library dependent. However, while testing wiringpi, the pigpio was mistakenly running, so the test must be repeated without it; ideally, by making direct kernel calls.

Affected images

So far, this behavior was observed on the following images:

• 2023-01-30-conveyorbot-focal-raspberry-pi
• 2023-02-14-ezmap-pro (lastest image)
• 2022-07-29-ezmap-pro (earliest released noetic image)

TODO

1. [ ] Test wiringpi without the pigpio daemon running
2. [ ] Test all GPIOs on the RPi & log behaviors
3. [ ] Try toggling GPIOs by making direct kernel calls
4. [ ] Find the noetic base image where it works and figure out the release when it stopped

[MoffKalast]

Yes, so the ezmap images I've tested are:

• 2023-02-14-ezmap-pro (lastest image)
• 2022-07-29-ezmap-pro (earliest released noetic image)

Both have the same problem. Another thing I've observed is that toggling GPIO 26 and 16 does not cause issues, while 13 does. Note that there is a pushbutton on the sonar board which is designed to be read by pifi to throw the robot into AP mode, which may be related to the problem. I don't think this is/are the pin/s for it, but something could be misconfigured

I've also tested one of my personal custom robot image backups that was made sometime late summer 2022 because I know it used the pin in question without problems, and strangely enough it does not have this problem. I'm not sure which noetic image it originally was, but it's probably one of the early noetic base ones. So that's our next lead I guess.

Possible culprits (imo):

• the way we install pigpio (this one seems more and more unlikely)
• rev 1.5 Pi firmware causing issues
• sonar board AP button related
• something else we've missed?

[ahrastnik]

So, I have done some research into this. So far, I haven't found anyone that has encountered this issue. However, I have found a few leads inside Device Tree overlays:

• There is a "gpio-shutdown" config, which makes the Pi poweroff if the chosen GPIO changes state. But this doesn't explain why WiFi drops, as I found no config for toggling WiFi.
• The only place where GPIO 6 and 13 are used together is in hd44780-lcd display config. Otherwise, those GPIOs are used for two UART interfaces.

I have also found this issue on the RPi forums, which describes a similar issue, albeit on a completely different GPIO.

[MoffKalast]

Hmm I've tried finding out which buttons the sonar board uses for its SW1 and SW2 but can't find the reference to it anywhere. Just to be sure, can you try commenting out "dtoverlay=ubiquity-led-buttons" and all the other i2c and serial stuff from /boot/config.txt to see if that does anything?

[MoffKalast]

Ah yes found it, https://learn.ubiquityrobotics.com/noetic_overview_raspberrypi#gpio-lines

GPIO | RasPi Pin | P702 Pin | Default Magni Usage -- | -- | -- | -- 5 | 29 | 29 | WiFi Status LED on the sonar board and rev 5.2 MCB 25 | 22 | 22 | Status LED on the sonar board 6 | 31 | 31 | Goes to P704 pin 2. Does a shutdown when grounded. This goes to a pushbutton on Sonar Board near 50 pin connector. 13 | 33 | 33 | Goes to P705 pin 2. Used for PiFi and goes to a pushbutton on the Sonar Board

It's intended behaviour, we're idiots 😄

[ahrastnik]

Yikes, indeed we are, so much for the cliff sensor inputs... 😅