Pwm not responding after autologin

[Roarge]

When running a script with bashrc using "sudo node /home/pi/test.js", node-rpi does not work with autologin. There is no caught error, and the scripts keeps running and responding to other calls, just not node-rpio. When logging in with the same user, but with password-login, the same script works fine.

What is interesting, is that after logging in over ssh using a password after autologin, the script running in the auologin user also becomes responsive.

It does not seem to be a timing issue. I have attempted adding as much as 30 s wait in case there is any hardware or peripherals that needs initializing.

The issue is also the same using /etc/profile.

[Roarge]

Using node 8.3 and the latest raspbian release, clean image except the node update.

[jperkin]

This approach is unlikely to work well, as bashrc will be sourced for every subshell as well as login shells. It's likely that there are conflicting processes running which is causing the problems here. You'd be better off creating a proper startup script for the process depending on your distribution init system. Either way this is an issue with the OS and its configuration and isn't something I can address in the library unfortunately.

[Roarge]

It does in fact appear to be an issue with node-rpio. I tested the script using raspi, and then there was no problem. Using various methods for autologin and startup scripts, pins are consistently unresponsive unless a second shell is opened over ssh. This is only an issue when using autologin, and no error is thrown. The script is still responsive to commands not using node-gpio.

[jperkin]

My point is that node-rpio not working is merely a symptom of an underlying problem. There's nothing I can do to fix issues with the OS not providing access either to the /sys/class device nodes or the /dev/gpiomem device, or with permissions to mmap device memory, depending on how you are using the library. The library simply uses the interfaces that the OS provides, and if those interfaces are not working correctly then unfortunately there's nothing I can do about it, other than document how to configure them correctly as I have done with /dev/gpiomem access permissions via udev.

In many situations it's not even possible to detect that it isn't working, for example if any secondary processes start to manipulate GPIO via /sys/class when node-rpio has already started using the mmap interface.

Sorry if this isn't a satisfactory answer, but other than continuing to document any issues there's really nothing I can do about it.

[gzphreak]

Any chance I can help debug this? I'm having the same issue. I'm not using an autologin feature, instead, I'm using a proper init.d script and forever to daemonize my node program. There are no errors produced when launching the library/script but nothing seems to work until I login and restart the init script.

[dlemper]

I also habe an issue with my lcd code (https://github.com/dlemper/lcd) only on first startup after boot using systemd service. I already tried to delay the execution of the script by 30 seconds, but that doesn't help..

Can we add some debug information to the c/c++ part?

I can add some more details and screenshots of the display and the code if desired.

Am 11.10.2017 um 00:01 schrieb Dan Clark notifications@github.com:

Any chance I can help debug this? I'm having the same issue. I'm not using an autologin feature, instead, I'm using a proper init.d script and forever to daemonize my node program. There are no errors produced when launching the library/script but nothing seems to work until I login and restart the init script.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gzphreak]

@dlemper I just changed all the fprintf calls to syslog and added some extra logging to verify successful initialization. The library thinks everything is copacetic. I'll keep digging.

[dlemper]

@gzphreak: the fprintf are not the interesting part as they only occur if the init function fails completely, where you would get a false as the return value. My thoughts are about messed up address pointers. Lets have a look at this:

define BMC2835_RPI2_DT_FILENAME "/proc/device-tree/soc/ranges"

If the data in this file (dynamically generated at boot from procfs, i think) is garbage, the base adress for the memory pointers is wrong.

My code is running on a Rasberry Pi Model A with 700MHz. Which one do you use? I just want to know, if it has something to do with thr model ;)

Am 11.10.2017 um 18:12 schrieb Dan Clark notifications@github.com:

@dlemper I just changed all the fprintf calls to syslog and added some extra logging to verify successful initialization. The library thinks everything is copacetic. I'll keep digging.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gzphreak]

@dlemper I'm running this code on a Raspberry Pi Zero W, which is the same architecture as the Model A. I have a few other models I could dig out as well, if needed.

[gzphreak]

@dlemper Take a look at this thread it looks like an addressing problem in the bcm2835_pwm_set_mode function in the bcm2835 library. I was able to get my code to work by adding dtoverlay=pwm-2chan and disabling audio in /boot/config.txt. Which enables pwm in the device tree. Another workaround suggested in the thread is to make a call to the gpio/wiringpi CLI(s) and access the pwm features, i.e. gpio pwm-bal.

[dlemper]

@gzphreak well done!

@jperkin this may be documented in the PWM section in the README.md, what do you think?