Ubuntu Mate and RPi.GPIO - Kernel settngs


#1

It looks like Ubuntu Mate has difficulties with using Python’s RPi.GPIO.

I am finding a Raspberry PI 3 with the Ubiquity Raspi image will segfault if running a python script that relies on RPi.GPIO.

From a forum post the issues appears to be:

“…The reason for the segfault is that the Ubuntu kernel was built with CONFIG_STRICT_DEVMEM set true. It was unset in the raspbian kernel. (It is a setting under Kernel Hacking)…”

Source: https://stackoverflow.com/questions/30442719/getting-segmentation-fault-when-using-rpi-gpio-setup-on-raspberry-pi-2


#2

Does this problem occur when you are running as sudo, or only as a normal user?

Our Ubuntu image uses the same kernel as Raspbian, so I doubt there is compile time configuration difference.

Rohan


#3

You are correct, I checked the Kernel config and see that CONFIG_STRICT_DEVMEM is not set so it can’t be that.

Settings that support GPIO usage are set correctly:
CONFIG_BCM2835_DEVGPIOMEM=y
CONFIG_DEVMEM=y

My error is that any Python code (ROS or a trivial program) that uses RPi.GPIO and then enters a loop will appear to segfault (by being non-responsive on an SSH or VNC session).

Having debugged a little more this morning I looks like there is no segfault, what is happening is running the python script is resetting the network connection (hence dropping SSH and VNC sessions and not allowing reconnection).

CPU and Swap are not being stressed and not crashes are reported by Apport.

I am using a static IPv4 set up on the Raspberry Pi (not the default Wifi AP setup). I will play with that and see if it fixes anything and report back here.


#4

I think I’ve found the source of the problem (thanks to your excellent pifi documentation Rohan)

So the problem is defined as when I manipulate GPIO pins I lost network connection (what I erroneously thought was a segfault or similar)

I suspect that this was because I was manipulating the PIN that is default mapped to the pifi button, this caused pifi to trap the pin change and interpret is as a button press.

I editted /etc/pifi/pifi.conf and set the button to “None”

I now don’t see the network reset.

I am still causing a shutdown signal to be set to the Raspberry Pi due to (I suspect) another pin I am manipulating. Does anyone know offhand which GPIO.BCM pin would be mapped to system shutdown in Magni?


#6

If you want to disable the buttons, you can remove the line with ubiquity-leds-buttons from your /boot/config.txt.

The pins used by this are: 5, 25 (status LEDs); 13 for the AP mode button, and 6 for the power button.


#7

In prior post I when Rohan says ‘pins’ he is discussing GPIO pin numbers and not the pin number on the hardware connector. I think people know that but just in case.