GPIO: polling a keyboard crashes the kernel after an hour or two...

[christophe-dupriez]

In Python, I poll rows and columns of a numerical keypad using GPIOs without added resistors
(I use the input pullups).
I followed this article:
http://www.instructables.com/id/Using-a-keypad-with-Raspberry-Pi/

_As the bug happens without key presses, one can test on any RPi even without any keypad plugged._

The GPIOs I use for rows and columns are:
ROW = [18,23,24,25]
COLUMN = [4,17,22]
After an hour or two, the kernel crashes badly using either "Rpi.GPIO" or "pigpio" (pigpio may be a bit longer to crash). The crashes are never the same and even the console frame buffer may be garbled.
I attach the keypadClass.py (.txt to make it accepted by GitHub) and keytest.py
I also attach photos of the Rpi console...

My question is: " what kind of workaroung could I follow to protect the Kernel from crashing when polling a keyboard ? "

Thanks a lot for your help !

Christophe

keypadClass.py.txt

keytest.py.txt

[pelwell]

A few questions:

1. How good is your power supply? Have you ever seen the under-voltage warning?
2. Are you overclocking? If so, what are your settings?

[christophe-dupriez]

Thanks pelwell !

I am not overclocking.
Very few and usual configuration options from a standard "headless" Raspbian.
I2C is activated (and working well). No SPI. Serial is used.
Like you, I suspected the power supply. But, I am pretty sure of it now:

• 12 V 3amps (with 7Ah battery backup)
  • 12V->5V 3amps DC/DC converter
• I measured always less than 350ma taken by the Rpi
• The problem arise also with simple wall plug power supply (Rpi certified, sold by Element14)

The whole application works perfectly when I do not poll the keypad.
A reduced application (only polling the keypad) is failing like the complete one.

I tested with two different RPi 2 model B.
I also reinstalled all the software on a new SD card (Sandisk).

Have a nice day!

[christophe-dupriez]

keypadClass2.py.txt
Looking at the Linux driver to read a keypad using a GPIO Matrix
http://lxr.free-electrons.com/source/drivers/input/keyboard/matrix_keypad.c
I modified my code to mimic it (see keypadClass2.py.txt NOW attached).
The only difference with Linux driver algorithm is that I set internal pull-down on input pins.

It crashes the Kernel even faster !

Pull-downs could be the problem for the Kernel ?
(by the way, firmware and Raspbian are at their latest version)

[christophe-dupriez]

My issue seems similar to:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=108461
Does somebody would have a solution / work around ?

[joan2937]

How are you using pigpio? Could you link to a full listing? pigpio C does allow the use of the SYSFS interface but it is discouraged except in exceptional circumstances which do not apply in your application.

[christophe-dupriez]

Dear Joan2937,

In keypadClass.py.txt (1st message) and keypadClass2.py.txt (NOW 2 messages above) you will find the calls to pigpio Python interface.

I also tested Rpi.GPIO with the same problems (may be a bit worse)

_As the bug happens without key presses, one can test on any RPi even without any keypad plugged._

[christophe-dupriez]

The answer to the question below may be the explanation + solution:
http://raspberrypi.stackexchange.com/questions/37397/rpi-gpio-mysteriously-crashing-when-setting-up-pin
It recommends to avoid Rpi.GPIO and "pigpio" which are accessing "/dev/mem/..." and to use WiringPi + its Python wrapper (using /sys/class/...). I will have a try tomorrow. If true, creators of RpiGPIO and "pigpio" should investigate how to strengthen up their software...

[joan2937]

@christophe-dupriez As the author of pigpio I'll point out that is rubbish. pigpio makes more use of /dev/mem than wiringPi which makes more use of /dev/mem than RPi.GPIO.

[christophe-dupriez]

Please excuse me, I did not meant to be rude in any way.

_What I know:_ using Rpi.GPIO or pigpio, I have a Kernel Crash.
I spent weeks thinking it was an I2C or a power problem and beefing up the hardware.
I could not imagine to have problems with something basic like GPIOs.
I may be wrong again.

_What I still have to test:_ using WiringPi, will it go better?
Before that, nothing objective, I agree.

Have a nice evening,

Christophe

[christophe-dupriez]

Just had a look to WiringPi source code: it uses /dev/mem and recently began to use /dev/gpiomem too.
GPIOMEM advantages and availability is discussed here:
#1112

[christophe-dupriez]

Kernel crashes as fast with /dev/gpiomem (latest WiringPi2) than with /dev/mem ...
The problem is therefore very low level as it is common to Rpi.GPIO, pigpio and WiringPi2, /dev/mem and /dev/gpiomem

I stopped changing pin modes from output to input (please look attached file keypadClass3.py.txt) and the Kernel seems to resist for now (3 hours later): wait & see after some days...

keypadClass3.py.txt

[christophe-dupriez]

Joan, as written here:
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=130903
it runs now a lot better without input/output mode switch.
I attach the code fitted for pigpio and working well for now (will see after a day)
keypadClass4.py.txt
I will stick to pigpio (and pigpiod) as it is the most robust and flexible architecture.
I also attach a photo of the setting...

[christophe-dupriez]

So after 36h, the Rpi is still up & running.
This means that the latest Kernel crashes after about an hour with the following combination:

• accessing /dev/mem or /dev/gpiomem 20 times per second
• alternating 3 GPIOs from output to input+pulldown.

My workaround being to alternate output for columns from 1 to 0, the danger is to shortcut two GPIOs when two button are pressed together on the same row: I will have to add resistors to my PCB: 1K ohms to limit current to 3ma when 2 keys on the same row are pressed at same time.

[lurch]

I suspect a minimal test script (just a single .py file) that uses RPi.GPIO (which is the 'officially supported' GPIO python interface) that reliably causes the kernel to crash, will be a great help to the kernel developers in diagnosing this problem.

[christophe-dupriez]

Now it has been running for days without a hitch (KeypadClass4.py.txt above). I suspect mode change (input+pull-down / output) to be the problem: so the failing python file cannot be really simpler than KeypadClass3.py.txt (one to two hour before failure) provided above. I will modify it for RPi.GPIO Wednesday or Thursday, which is rather a straightforward task. (Suffix ".txt" added to the file name to make it accepted by this forum)