Linux: 4.14 freezes when GPIO is pulled high

[antroseco]

Since upgrading my Raspberry Pi Zero to the 4.14 kernel from 4.9, every time a GPIO pin is read and it is high, the device freezes and has to be reset. I couldn't find anything in the logs related to this.
The GPIO pins are accessed through /dev/gpiomem/.

[pelwell]

Which utility are you using - raspi-gpio?

With which GPIOs have you seen this freeze?

[antroseco]

I'm using rpio which uses the bcm2835-gpiomem kernel module. I've seen this happen with physical pins 12, 16, 22, 26 (not exhaustive, only the ones I've tested).
I've just noticed that pin 26 is SPI Chip Select 1, but as far as I know SPI was meant to be off by default.

[pelwell]

If you have any external hardware attached to the 40-pin header, please disconnect it and retest.

[antroseco]

I don't have anything connected other than a couple of outputs connected to relays and an input. The input's source is 16V and has a current-limiting 33kΩ resistor attached in series (so maximum current is under 0.5mV, well with-in the the pi's capabilities).
This setup works fine with 4.9, but crashes 4.14.

[pelwell]

The input's source is 16V

Really? GPIOs are only 3.3V capable.

This setup works fine with 4.9, but crashes 4.14.

Yes, you did say that. I want to narrow down where the fault might be, so please disconnect your hardware from the 40-pin header and retest. If that shows no problems, try reconnecting the pins one at a time to determine which make a difference.

[antroseco]

Alright, I'll de-solder everything when I have the time and report back.
Thanks.

[adamreisnz]

I think I am having the same issue on our Raspberry Pi's Model 3. They freeze/crash occasionally when trying to read an input pin that has been initialised with a pull up. I've tried different pins (physical pins 29 and 31), with the same result.

This can be reproduced with or without any physical connections to the input, e.g. also crashes when you simply try to read the pin without it being connected to anything.

Using standard Raspberry Pi power source, no external hardware connected.

This has only started happening after I started using the latest Raspbian image.

@pelwell any thoughts on what I could do to help you debug this? Otherwise we see no option but to downgrade all devices back to 4.9.

[adamreisnz]

Here's a simple Node script that reproduces the issue

const rpio = require('rpio');
const {INPUT, OUTPUT, HIGH, LOW, PULL_UP} = rpio;
const pin = 29;

console.log('Opening pin');
rpio.open(pin, INPUT, PULL_UP);
console.log('Pin opened');

console.log('Reading state');
const state = rpio.read(pin) || LOW
console.log(`Pin state is ${state}`);

console.log('Setting up polling');
rpio.poll(pin, pin => {
  console.log('In poll cycle');
  console.log('Reading state');
  const state = rpio.read(pin) || LOW
  console.log(`Pin state is ${state}`);
});

console.log('End of script');

Removing the PULL_UP statement resolves the issue, but running it like this causes the Pi to crash on the rpio.poll statement.

Note that this does not happen 100% consistently, but about 95% of the time if you run this shortly after a reboot. For some reason, after some time passes and I make some changes to the script etc. and run it again, it runs fine. But then when I run it after a reboot, it crashes again.

[ASwingler]

I'm seeing the same behavior. The problem appears to exist with /dev/mem* as well as dev/gpiomem.

Andrew.

[pelwell]

Are you using the correct numbering scheme? I don't know the node 'rpio' library beyond a cursory scan of the source, but I think it uses the official "Broadcom" GPIO numbering scheme. This labels 54 of the SoC pins as GPIO0 to GPIO53. GPIO2 to GPIO27 are brought out onto the 40 pin header - the rest are used to control other features of the Pi. Note that the GPIO number to pin number map is not a simple linear map: GPIO 4 is on header pin 7, while GPIO 5 is on header pin 29.

Why does this matter for your use case? Pin 31, which you mention, carries GPIO6, while GPIO31 can control anything from the RTS line of the Bluetooth modem to the reset line for the USB Hubs/Ethernet controller. If you are in doubt, use the raspi-gpio utility (https://github.com/RPi-Distro/raspi-gpio) to examine the pin functions and control the pull settings - I choose it because it only uses the BRCM scheme (which is a close match for the SoC hardware).

[adamreisnz]

Yes, we're using the physical numbering scheme (1-40) as supported by rpio. As mentioned, this works flawlessly on kernel 4.9, but breaks on 4.14.

Rpio also supports the GPIO numbering scheme, but we aren't using that. So whenever I mention a pin number, I'm referring to the physical pin number.

However, I don't think which pin it is matters much, as we've experienced the issue with pins 29 and 31 (the only ones I tested), and @KimJongSkill has reported issues with physical pins 12, 16, 22, 26. So it seems a wide range of different pins are affected.

[ASwingler]

I see the same behavior on various pins. I'm using GPIO numbering.

[pelwell]

Are any of you not using the Node rpio library? (I'm not saying it is at fault, but it might be different in a significant way).

[ASwingler]

I did a test using the Node 'onoff' library and was unable to replicate the problem. I've not tested other libraries.

[adamreisnz]

@pelwell One of the first things I tried was rolling back to older versions of rpio, but when I investigated further, I noticed there hadn't been any significant code changes done at all in the past few months that would suddenly cause it stop working.

I didn't test any other libraries as this one seems to be the best maintained one. Some of the other libraries haven't been updated in 2 years.

I also tried on different versions of Node, but same result.

The only thing that fixes it for me at the moment is rolling back to the 4.9 kernel.

Could any clues be found in the bcm2835-gpiomem kernel module as @KimJongSkill mentioned?

[pelwell]

I really don't think so - all /dev/gpiomem does is map the GPIO registers for user space - a restricted version of /dev/mem which doesn't need root privileges to access.

[adamreisnz]

Would you have any recommended place to look for clues as to why it's causing the crash? I've examined syslog and a variety of other logfiles, but couldn't find any clues. The device essentially just freezes.

Any chance you could have a chat with the maintainer of rpio (@jperkin) to try and figure out what could be happening? He'll probably know more about what the library is doing and how any kernel update changes could be affecting the package.

[jperkin]

The backend of rpio uses Mike McCauley's bcm2835 library to handle mmap()ing the /dev/{gpio,}mem bits. As far as I'm aware all the other nodejs modules use the slower /sys interface which is why they wouldn't exhibit the same issues (the reason I wrote rpio in the first place was because I wanted a faster interface than the existing modules provided).

I can't see how nodejs would be affecting the behaviour here, but you could always just use the bcm2835 library directly and write a simple C program to perform the same functions to rule it out.

I don't have any hardware running newer kernels to verify this at the moment unfortunately.

[pelwell]

It doesn't make much sense to me - kernel changes should have no effect on how rpio works because rpio is essentially a driver that runs in userspace, and it hasn't changed.

The only hypothesis so far is that the kernel is manipulating the GPIO hardware at the same time as rpio, and without any kind of synchronisation it ends up changing a critical pull in the wrong direction.

[pelwell]

Any ideas how I can install the rpio library on 4.17? I get the following output from npm install rpio:

pi@raspberrypi:~ $ npm install rpio
|
> [email protected] install /home/pi/node_modules/rpio
> node-gyp rebuild

gyp: Call to 'node -e "require('nan')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/usr/share/node-gyp/lib/configure.js:304:16)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:12)
gyp ERR! System Linux 4.17.1-v7+
gyp ERR! command "/usr/bin/nodejs" "/usr/bin/node-gyp" "rebuild"
gyp ERR! cwd /home/pi/node_modules/rpio
gyp ERR! node -v v4.8.2
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok 
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian

npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script.
npm ERR! This is most likely a problem with the rpio package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls rpio
npm ERR! There is likely additional logging output above.

npm ERR! System Linux 4.17.1-v7+
npm ERR! command "/usr/bin/nodejs" "/usr/bin/npm" "install" "rpio"
npm ERR! cwd /home/pi
npm ERR! node -v v4.8.2
npm ERR! npm -v 1.4.21
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/pi/npm-debug.log
npm ERR! not ok code 0

[antroseco]

Looks like you are using a very old version of node (finally something I can help with lol)

[pelwell]

Direct user-space access to hardware may be fast, but it is non-portable and runs the risk of atomicity issues (as this may be). Linux has a new character device interface - libgpiod - which should be much more efficient than the sysfs interface whilst still remaining portable.

[ASwingler]

The device doesn't freeze when this happens. Access to I/O devices (USB, network) stops but the machine keeps running - if you run top with a fast refresh (for instance top -id 0.125) you'll see activity.
This problem also happens with /dev/mem* so it's not a /dev/gpio issue.

I noticed the problem with a kernel updated around the March '18 timeframe. Previously the same nodejs code had been stable. It didn't seem as though rpio had been updated around that time so I feel that a change in the kernel caused this to start happening.

It seems as though it's some kind of i/o initialization issue that's causing the problem - if I can get the thing to run, it will continue to run without failing until the next boot. Stopping/starting node.js seems to have no impact on the problem. It also doesn't matter how long the system has been running - it happens on the first run after reboot (but not every time).

Andrew.

[pelwell]

Thanks, @KimJongSkill, I've got node updated now, and rpio is installed. I'll have a play for a bit and report back.

[jperkin]

FWIW rpio should build fine on any nodejs version since 0.8 (travis confirms this, each push is tested on every version and all are currently green), unfortunately npm and gyp are a pile of crap and will often fail for spurious reasons with no useful information, as in this case. Sorry for the terrible user experience :(

[pelwell]

I can recreate the issue, or at least I'm getting lockups running the GPIO test script, but I won't get much time until next week.

[adamreisnz]

Great, thanks for looking into it @jperkin and @pelwell.

@ASwingler thanks for correcting me. I assumed the devices freezes, but you're right it does still stay on, but loses all network connectivity and USB, so from the outside it appears dead.

I also noticed that once it's running, it will work fine. While debugging, I found that it worked one time after reboot after I had downgraded Node, so I thought I found the problem, but then after the next reboot it failed again. Seemed pretty random in the end.

[pelwell]

Getting further: I can get a lock-up reliably in two simple steps:

pi@raspberrypi:~$ node gpiotest.js
Opening pin
UP
Reading state
Pin state is 1
Setting up polling
End of script
In poll cycle
Reading state
Pin state is 1
^C
pi@raspberrypi:~$ raspi-gpio set 5 pd

Breaking out of the script leaves the event bits for rising and falling edges on GPIO5 (pin 29) enabled. Subsequently setting the pull in the opposite direction seems to be the fatal step, presumably because it causes the input level to change. In fact, replacing the raspi-gpio invocation with pull the pin down using a patch cable is enough to kill the system. Clearing the event bits before changing the pin level avoids the problem.

[pelwell]

The architecture of the GPIO block assumes that event detection will only be enabled in order to generate interrupts. As a result there is no independent interrupt enable bit for each GPIO.

Enabling the event detection bits without a kernel driver is killing the interrupt system because there is nothing to handle the interrupt and clear the bit. The GPIO driver could be modified to clear the event bits before or after calling any interrupt handler, but either would break the (IMO invalid) way the rpio library is using event detection because there would be a chance that an event was cleared before the user-space polling thread noticed that it had been set.

The issue was present on the 4.9 kernel, but due to a different implementation the IRQ was trapped and disabled after 100000 spurious interrupts. Unfortunately the interrupt in question is the interrupt for bank 0, so there is a lot of collateral damage.

I suggest (again) that you investigate the libgpiod API, or remove the event generation and live with the fact that some brief pulses may be missed.

[pelwell]

Thinking about this issue some more, there is a workaround you could consider which is sacrificing all GPIO-generated interrupts. Depending on your use cases this may not be a viable option - it would break the gpio-key and gpio-shutdown overlays, for a start.

If you think this could be useful I have an overlay you to try: https://drive.google.com/open?id=1dM7FQeHod-vVR_JgwMeeitIWaqHC03wA

Copy it to /boot/overlays/gpio-no-irq.dtbo, add dtoverlay=gpio-no-irq to config.txt and reboot. You should then be able to the rpio and change the pulls to your heart's content.

[pelwell]

(raspi-gpio raw can be used to show the register state before and after running the node script - you'll notice that REN0 (0x4c) and FEN0 (0x58) have bit 5 set after the first run, which would normally cause a problem if the pin level is subsequently changed.)

[antroseco]

Thanks a lot for taking the time to look into this, the overlay works great until I find a more "permanent" solution.

[pelwell]

It's in the rpi-4.14.y tree now, so it will be a standard overlay as of the next release.

[antroseco]

Great, I guess I can close this now. Thank you.

[adamreisnz]

Thanks for finding a solution. Does this mean the issue will be resolved in the operating system side of things or is it still recommended for @jperkin to make some changes to the rpio package?

[pelwell]

The overlay comes with a few caveats, so I would say at best you have a workaround. It's possible that future (and perhaps even current) hardware would rely on GPIO interrupts, in which case another solution would have to be found.

[djensenius]

Hi @pelwell I am just following up on this issue. Is there anyway to use gpio-no-irq, except for the shutdown pin?

[pelwell]

No, but there is a gpio-key-polled (or gpio-polled-key) driver which could be used instead for shutdown detection with a modified overlay, provided the driver is enabled.

[fivdi]

I didn't test any other libraries as this one seems to be the best maintained one. Some of the other libraries haven't been updated in 2 years.

@adamreisnz onoff and pigpio are also very well maintained (even if I may say so myself :smile:)

The backend of rpio uses Mike McCauley's bcm2835 library to handle mmap()ing the /dev/{gpio,}mem bits. As far as I'm aware all the other nodejs modules use the slower /sys interface which is why they wouldn't exhibit the same issues (the reason I wrote rpio in the first place was because I wanted a faster interface than the existing modules provided).

@jperkin onoff uses the sysfs interface and can detect approximately 20,000 state changes per second with this test program on a Raspberry Pi 4. An equivalent rpio test program can detect approximately 923 state changes per second.

[pelwell]

The ioctl-based libgpiod API should easily outperform the sysfs API.

[fivdi]

The ioctl-based libgpiod API should easily outperform the sysfs API.

While this is likely to be the case in many scenarios, I'm not sure if it will be the case with Node.js. In Node.js applications there is normally only one JavaScript thread and blocking calls in this thread are regarded as being a bad practice. Under the covers, onoff uses epoll to detect state changes. It looks like libgpiod uses ppoll to detect state changes. To avoid blocking the JavaScript thread, it's necessary to start a C/C++ thread in the background. This background thread can then make blocking epoll/ppoll calls. When the background thread detects a state change, it needs to inform the JavaScript thread about the state change. This results in context switching between the threads which comes with a cost. I'm not sure if using libgpiod in combination with ppoll will be any faster than sysfs in combination with epoll.

@pelwell why do you think the libgpiod API should easily outperform the sysfs API for state change notifications?

[pelwell]

libgpiod cuts out several layers of software compared to sysfs - it allows multiple GPIOs (or a single GPIO repeatedly) to be queried and controlled from a single open file descriptor. There may be some use cases where the extra overheads of sysfs matter less, and your edge event case may be one of them, but that doesn't mean that libgpiod isn't superior.

You should also consider what the kernel documentation says:

GPIO Sysfs Interface for Userspace
==================================

THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO
Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS
ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL
NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED.

[nahshonw]

As google points here, I'm hesitant to start another topic on the same issue.

Problem:
Raspberry Pi 3B+ hangs a few seconds AFTER I run the Traffic Light code below.
Please note that the code runs with no errors but on SIGINT the Pi Freezes after a few seconds. Details of my system are beneath this code.

https://github.com/simonprickett/nodepitrafficlights/blob/master/index.js
const gpio = require('onoff').Gpio

const red = new gpio(17, 'out')
const yellow = new gpio(27, 'out')
const green = new gpio(22, 'out')

const sleep = (howLong) => {
  return new Promise((resolve) => {
    setTimeout(resolve, howLong)
  })
}

const runLights = async () => {
  while (true) {
    // Red
    red.writeSync(1)
    console.log("Red Light");
    await sleep(3000)
    // Red and Yellow
 console.log("Yellow and Red Lights");
    yellow.writeSync(1)
    await sleep(1000)
    // Green
    red.writeSync(0)
    yellow.writeSync(0)
    green.writeSync(1)
 console.log("Green Light");
    await sleep(5000)
    // Yellow
    green.writeSync(0)
    yellow.writeSync(1)
 console.log("Yellow Light");
    await sleep(2000)
    // Yellow off
    yellow.writeSync(0)
  }
}

const allLightsOff = () => {
  red.writeSync(0)
  yellow.writeSync(0)
  green.writeSync(0)
 console.log("All Off");

}

// Handle Ctrl+C exit cleanly
process.on('SIGINT', () => {
  allLightsOff()
  process.exit()
})

allLightsOff()
runLights()

This is a clean system with little else installed, please see below:

pi@gpio:~ $ node -v
v14.11.0

pi@gpio:~ $ uname -a
Linux gpio 5.4.65-v7+ #1341 SMP Tue Sep 15 13:07:34 BST 2020 armv7l GNU/Linux

pi@gpio:~ $ cat /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2

Home Directory Permissions:

Raspberry Pi 3 Model B Rev 1.2pi@gpio:~ $ ls -lah
total 104K
drwxr-xr-x 9 pi   pi   4.0K Sep 22 18:54 .
drwxr-xr-x 3 root root 4.0K Aug 20 11:31 ..
-rw------- 1 pi   pi   1.1K Sep 22 17:44 .bash_history
-rw-r--r-- 1 pi   pi    220 Aug 20 11:31 .bash_logout
-rw-r--r-- 1 pi   pi   3.7K Sep 20 12:19 .bashrc
-rw-r--r-- 1 pi   pi    799 Sep 21 00:25 blink.js
drwxr-xr-x 3 pi   pi   4.0K Sep 20 23:49 .cache
drwx------ 3 pi   pi   4.0K Sep 20 23:48 .config
drwx------ 3 pi   pi   4.0K Sep 20 11:45 .gnupg
drwxr-xr-x 3 pi   pi   4.0K Sep 20 23:57 .local
drwxr-xr-x 8 pi   pi   4.0K Sep 22 18:37 node_modules
drwxr-xr-x 5 pi   pi   4.0K Sep 21 00:38 .npm
drwxr-xr-x 5 pi   pi   4.0K Sep 20 23:48 .nvm
-rw-r--r-- 1 pi   pi    245 Sep 20 23:49 package.json
-rw-r--r-- 1 pi   pi   1.8K Sep 20 23:49 package-lock.json
-rw-r--r-- 1 pi   pi   7.1K Sep 22 18:38 piHomeTree.txt
-rw-r--r-- 1 pi   pi    27K Sep 22 18:40 piInstalledPackages.txt
-rw-r--r-- 1 pi   pi    807 Aug 20 11:31 .profile
-rw-r--r-- 1 pi   pi   1.0K Sep 21 00:07 traffic.js
pi@gpio:~ $

I have tried with Archlinux and Raspberry Pi OS for a few days, all with the same "freezing" result:
Below is the /boot/config.txt with these extra entries:

dtoverlay=gpio-no-irq
and 
dtoverlay=gpio-poweroff,gpiopin=2,active_low

The 8 Channel Relay I'm using is active low so I need the pins high on reboot.
I have run the code with the GPIO pins disconnected from the Relay and the raspberry Pi still freezes.

pi@gpio:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=off
#dtparam=i2s=on
dtparam=spi=off

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
start_x=0
enable_uart=0
dtoverlay=gpio-no-irq
dtoverlay=gpio-poweroff,gpiopin=2,active_low
dtoverlay=gpio-poweroff,gpiopin=3,active_low
dtoverlay=gpio-poweroff,gpiopin=4,active_low
dtoverlay=gpio-poweroff,gpiopin=17,active_low
dtoverlay=gpio-poweroff,gpiopin=27,active_low
dtoverlay=gpio-poweroff,gpiopin=22,active_low
dtoverlay=gpio-poweroff,gpiopin=10,active_low
dtoverlay=gpio-poweroff,gpiopin=9,active_low
dtoverlay=gpio-poweroff,gpiopin=11,active_low
dtoverlay=gpio-poweroff,gpiopin=0,active_low
dtoverlay=gpio-poweroff,gpiopin=5,active_low
dtoverlay=gpio-poweroff,gpiopin=6,active_low
dtoverlay=gpio-poweroff,gpiopin=13,active_low
dtoverlay=gpio-poweroff,gpiopin=19,active_low
dtoverlay=gpio-poweroff,gpiopin=26,active_low
pi@gpio:~ $

Here is the tree of my home folder:

pi@gpio:~ $ cat piHomeTree.txt
.
├── blink.js
├── node_modules
│   ├── bindings
│   │   ├── bindings.js
│   │   ├── LICENSE.md
│   │   ├── package.json
│   │   └── README.md
│   ├── epoll
│   │   ├── binding.gyp
│   │   ├── build
│   │   │   ├── binding.Makefile
│   │   │   ├── config.gypi
│   │   │   ├── epoll.target.mk
│   │   │   ├── Makefile
│   │   │   └── Release
│   │   │       ├── epoll.node
│   │   │       └── obj.target
│   │   │           ├── epoll
│   │   │           │   └── src
│   │   │           │       └── epoll.o
│   │   │           └── epoll.node
│   │   ├── epoll.js
│   │   ├── example
│   │   │   ├── interrupts-per-second
│   │   │   │   ├── export
│   │   │   │   ├── interrupts-per-second.js
│   │   │   │   └── unexport
│   │   │   └── watch-button
│   │   │       ├── export
│   │   │       ├── unexport
│   │   │       └── watch-button.js
│   │   ├── History.md
│   │   ├── LICENSE
│   │   ├── package.json
│   │   ├── README.md
│   │   ├── src
│   │   │   ├── epoll.cc
│   │   │   └── epoll.h
│   │   └── test
│   │       ├── closed.js
│   │       ├── coin-acceptor
│   │       │   ├── avr-build
│   │       │   ├── coin-acceptor.c
│   │       │   ├── coin-counter-fail.js
│   │       │   ├── coin-counter-success.js
│   │       │   └── output
│   │       ├── do-almost-nothing.js
│   │       ├── do-nothing.js
│   │       ├── no-gc-allowed.js
│   │       ├── one-shot.js
│   │       ├── performance-check.js
│   │       ├── run-tests
│   │       ├── stress
│   │       │   └── brute-force-leak-check.js
│   │       ├── two-shot.js
│   │       ├── util.js
│   │       └── verify-events.js
│   ├── file-uri-to-path
│   │   ├── History.md
│   │   ├── index.d.ts
│   │   ├── index.js
│   │   ├── LICENSE
│   │   ├── package.json
│   │   ├── README.md
│   │   └── test
│   │       ├── test.js
│   │       └── tests.json
│   ├── lodash.debounce
│   │   ├── index.js
│   │   ├── LICENSE
│   │   ├── package.json
│   │   └── README.md
│   ├── nan
│   │   ├── CHANGELOG.md
│   │   ├── doc
│   │   │   ├── asyncworker.md
│   │   │   ├── buffers.md
│   │   │   ├── callback.md
│   │   │   ├── converters.md
│   │   │   ├── errors.md
│   │   │   ├── json.md
│   │   │   ├── maybe_types.md
│   │   │   ├── methods.md
│   │   │   ├── new.md
│   │   │   ├── node_misc.md
│   │   │   ├── object_wrappers.md
│   │   │   ├── persistent.md
│   │   │   ├── scopes.md
│   │   │   ├── script.md
│   │   │   ├── string_bytes.md
│   │   │   ├── v8_internals.md
│   │   │   └── v8_misc.md
│   │   ├── include_dirs.js
│   │   ├── LICENSE.md
│   │   ├── nan_callbacks_12_inl.h
│   │   ├── nan_callbacks.h
│   │   ├── nan_callbacks_pre_12_inl.h
│   │   ├── nan_converters_43_inl.h
│   │   ├── nan_converters.h
│   │   ├── nan_converters_pre_43_inl.h
│   │   ├── nan_define_own_property_helper.h
│   │   ├── nan.h
│   │   ├── nan_implementation_12_inl.h
│   │   ├── nan_implementation_pre_12_inl.h
│   │   ├── nan_json.h
│   │   ├── nan_maybe_43_inl.h
│   │   ├── nan_maybe_pre_43_inl.h
│   │   ├── nan_new.h
│   │   ├── nan_object_wrap.h
│   │   ├── nan_persistent_12_inl.h
│   │   ├── nan_persistent_pre_12_inl.h
│   │   ├── nan_private.h
│   │   ├── nan_string_bytes.h
│   │   ├── nan_typedarray_contents.h
│   │   ├── nan_weak.h
│   │   ├── package.json
│   │   ├── README.md
│   │   └── tools
│   │       ├── 1to2.js
│   │       ├── package.json
│   │       └── README.md
│   └── onoff
│       ├── examples
│       │   ├── accessible.js
│       │   ├── blink-led-async.js
│       │   ├── blink-led.js
│       │   ├── blink-led-promises.js
│       │   ├── debounce-button.js
│       │   ├── light-switch.js
│       │   ├── light-switch.png
│       │   ├── mygpio-overlay.dts
│       │   ├── run-examples
│       │   └── wait-for-interrupt.js
│       ├── History.md
│       ├── integration-test
│       │   ├── blink-led.js
│       │   ├── blink-led-promises.js
│       │   ├── change-configuration.js
│       │   ├── configure-and-check-active-low-defaults.js
│       │   ├── configure-and-check-active-low.js
│       │   ├── configure-and-check-input.js
│       │   ├── configure-and-check-output.js
│       │   ├── debounce.js
│       │   ├── dont-reconfigure-direction-part1.js
│       │   ├── dont-reconfigure-direction-part2.js
│       │   ├── export-many-times.js
│       │   ├── high-low.js
│       │   ├── many-interrupts.js
│       │   ├── output-with-edge-bug.js
│       │   ├── performance-async.js
│       │   ├── performance-interrupt.js
│       │   ├── performance-sync.js
│       │   ├── run-performance-tests
│       │   ├── run-tests
│       │   ├── wait-for-interrupt.js
│       │   └── wait-for-many-interrupts.js
│       ├── LICENSE
│       ├── onoff.d.ts
│       ├── onoff.js
│       ├── package.json
│       └── README.md
├── package.json
├── package-lock.json
├── piHomeTree.txt
└── traffic.js

24 directories, 141 files

[pelwell]

Can you explain this section of your config.txt:

dtoverlay=gpio-no-irq
dtoverlay=gpio-poweroff,gpiopin=2,active_low
dtoverlay=gpio-poweroff,gpiopin=3,active_low
dtoverlay=gpio-poweroff,gpiopin=4,active_low
dtoverlay=gpio-poweroff,gpiopin=17,active_low
dtoverlay=gpio-poweroff,gpiopin=27,active_low
dtoverlay=gpio-poweroff,gpiopin=22,active_low
dtoverlay=gpio-poweroff,gpiopin=10,active_low
dtoverlay=gpio-poweroff,gpiopin=9,active_low
dtoverlay=gpio-poweroff,gpiopin=11,active_low
dtoverlay=gpio-poweroff,gpiopin=0,active_low
dtoverlay=gpio-poweroff,gpiopin=5,active_low
dtoverlay=gpio-poweroff,gpiopin=6,active_low
dtoverlay=gpio-poweroff,gpiopin=13,active_low
dtoverlay=gpio-poweroff,gpiopin=19,active_low
dtoverlay=gpio-poweroff,gpiopin=26,active_low

At best it's a bit strange.

[nahshonw]

I added that section to set the state of the pins when the rPi is powered on as detailed here:
https://www.raspberrypi.org/forums/viewtopic.php?t=175161

The relay board linked to above is active low. So I want to prevent the relays from activating when there is a power disconnection.

[pelwell]

Each instance of gpio-poweroff overwrites the previous one so only one of them has any effect - the last one.

The only sure way to avoid glitches on GPIOs is to make use of the default pulls, rather than trying to change them.

[nahshonw]

Thank you, yes it did feel strange pasting each line.

I found this:
gpio=2,3,4,17,27,22,10,9,11,0,5,6,13,19,26=pu,dh,op

Here:
https://www.raspberrypi.org/forums/viewtopic.php?t=246967

Is there anything you would like me to try?

[nahshonw]

I updated the /boot/config.txt and the good news is I can see the pull up resistors are working.
Unfortunately the freezing/crashing persists.

[ASwingler]

Make sure you didn't accidentally remove the "dtoverlay=gpio-no-irq" line -
that would cause a lockup.

On Tue, Sep 22, 2020 at 1:16 PM Nahshon Williams [e-mail]
wrote:

I updated the /boot/config.txt and the good news is I can see the pull up
resistors are working.
Unfortunately the freezing/crashing persists.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/linux/issues/2550#issuecomment-696955613,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD7O7WJNLGV4PN75JBSDBI3SHEA3HANCNFSM4E7HAE5A
.

[Granjow]

@nahshonw A different suggestion – instead of changing the way the Raspi IOs work with /boot/config.txt, I would change the hardware so you are not bound to this custom configuration (which is probably not visible in your software).

The relay module is active low, but you have normally closed and normally open. Why not connect the thing you want to control to the other connector (normally open) so the lights are off when there is no input?

[nahshonw]

Thank you, yes I did check and the file is fine.
I made a video of the pi freezing here
In the description of the video you can see what is happening.

Here is the updated /boot/config.txt file:

cat /bootpi@gpio:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=off
#dtparam=i2s=on
dtparam=spi=off

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
start_x=0
enable_uart=0
dtoverlay=gpio-no-irq
gpio=2,3,4,17,27,22,10,9,11,0,5,6,13,19,26=pu,dh,op

[nahshonw]

@nahshonw A different suggestion – instead of changing the way the Raspi IOs work with /boot/config.txt, I would change the hardware so you are not bound to this custom configuration (which is probably not visible in your software).

The relay module is active low, but you have normally closed _and_ normally open. Why not connect the thing you want to control to the other connector (normally open) so the lights are off when there is no input?

The relays are for powering up some Vacuum Fluorescent Displays which need a lot of current when powered on, so I switch all seven on in sequence to protect the power supply.
Yes they are connected to the normally open terminal on the relays.

[pelwell]

As mentioned in a Raspberry Pi Forums post (which I won't link to because it just duplicates effort) I am looking at GPIO edge detection for another reason, so I may have something to add in a few days.

[wintersteiger]

My RPI4 suffered from the same symptoms and, dtoverlay=gpio-no-irq does indeed fix it. However, libgpiod must be relying on those interrupts, because it ceases to work after enabling this overlay. I have two implementations of the same concept, one using libgpiod, the other using the bcm2835 library and I'd like to compare them without having to reboot. Is there a way to load the overlay temporarily or to re-enable IRQs during/after initialization of libgpiod?