Pi hangs w/ buster when pin value changes

[jlit]

It appears that this library suffers from the same issue as rpio with regard to interrupts on newer versions of Raspbian? The solution proposed there is to disable interrupts via dtoverlay=gpio-no-irq but that prevents other hardware that depends on interrupts from working. Are there any other work-arounds?

[fivdi]

This is the first time I've heard of this issue and I'm unable to reproduce the issue with the onoff integration tests on Buster.

Please provide a simple but complete program that can be used to reproduce the issue.

Please also provide the output of the following commands when run on the Raspberry Pi:

cat /etc/debian_version
uname -a
node -v

[fivdi]

This appears to be a related issue raspberrypi/linux#2550, however onoff doesn't appear to suffer from this issue.

[jlit]

@fivdi Thanks for taking the time to look into this. I was out for a few days but I'll work on putting together a small repro. It might be related to other hardware I have on the pi (I have an ezconnect board between the pi and a PICAN2 CANBus card. )

[jlit]

@fivdi First, I don't think there is a fundamental problem so I will close the issue. But I did get some fairly interesting findings by messing with pin/port numbers and hardware.

The code I was testing with is super simple, just the blink example plus a watch on another pin:

var Gpio = require('onoff').Gpio;
var LED = new Gpio(4, 'out');
var ignitionSwitch = new Gpio(21, 'in', 'both', {debounceTimeout: 10})
var blinkInterval = setInterval(blinkLED, 250);

ignitionSwitch.watch((err, value) => {
  console.log('ignition: ', err, value);
  LED.writeSync(value);
});

function blinkLED() { //function to start blinking
  if (LED.readSync() === 0) { //check the pin state, if the state is 0 (or off)
    LED.writeSync(1); //set pin state to 1 (turn LED on)
  } else {
    LED.writeSync(0); //set pin state to 0 (turn LED off)
  }
}

function endBlink() {
  clearInterval(blinkInterval);
  LED.writeSync(0);
  // LED.unexport();
}

setTimeout(endBlink, 5000); //stop blinking after 5 seconds

However, when I first started, I accidentally used the pin number, not the GPIO number so line 3 read var ignitionSwitch = new Gpio(40, 'in', 'both', {debounceTimeout: 10}), not 21.

With that code and without the PICAN2 board, I could not get the pi to hang. Of course, I also wasn't getting any hits on the pin either, because I was watching some non-existent pin. With that code and the PICAN2 board, the pi would hang anytime any pin was touched with a wire, even when the wire wasn't grounded or attached to voltage.

I can't really explain this, but with the code reduced to just this:

var Gpio = require('onoff').Gpio;
var LED = new Gpio(4, 'out');
var blinkInterval = setInterval(blinkLED, 1000);

function blinkLED() { //function to start blinking
  if (LED.readSync() === 0) { //check the pin state, if the state is 0 (or off)
    LED.writeSync(1); //set pin state to 1 (turn LED on)
  } else {
    LED.writeSync(0); //set pin state to 0 (turn LED off)
  }
  console.log('blink: ', new Date().getTime());
}

It would run forever without the PICAN2 but would hang as soon as any pin was touched while the PICAN2 was attached. I tried reproing that again just now and noticed that the console logging, which should happen every second, stalls for about 10 seconds when a pin is touched, and my bluetooth kb and mouse hang but then the "blink" console logs start up again so the pi isn't completely hung.

Yet, the original code with the pin properly set to 21 works correctly, with or without the PICAN2 board attached. Therefore, while I'm still confused as to why it was/is hanging/ish with no ignitionSwitch watch, I'm closing the issue.

[jlit]

Oh, and if you still want it:
debian_version: 10.4
uname: Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
node: v10.21.0

[fivdi]

@jlit Thank you for providing the feedback.

A Raspberry Pi has 53 GPIOs but many of them are not broken out to the 40 pin GPIO header. See here. I don't know if it's valid to use GPIO40 and I don't know if using it can have negative consequences.