I have a B+ v1.2, with a motor controller and 2 quadrature encoders setup. It's running Arch: 4.19.69-2-ARCH armv6l. It's completely locking up, requiring a plug-pull when either of the encoders trigger.


I am using 2 of these encoders. They are 3 wire hall effect sensors. The outputs are connected to Pin 3 and Pin 5 (BCM 2 and BCM 3), the i2c pins, but I have not enabled i2c in my boot.config, and also have the i2c kernel modules blacklisted.

Here is how they are connected (I used whatever 3-wire hall sensor I could find in Fritzing):

enter image description here


Here is the relevant code, using the bcm2835 C library:

#define A_ENC   RPI_BPLUS_GPIO_J8_03 //BCM2 (SDA)
#define B_ENC   RPI_BPLUS_GPIO_J8_05 //BCM3 (SCL)

//Setup encoders for input (SDA and SCL pins already have a pullup!)
bcm2835_gpio_fsel(A_ENC, BCM2835_GPIO_FSEL_INPT);
//bcm2835_gpio_fsel(B_ENC, BCM2835_GPIO_FSEL_INPT);


Attempted diagnoses

I've narrowed the issue down to after I setup the pins with either bcm2835_gpio_aren or bcm2835_gpio_afen and then the corresponding encoders trigger.

This causes all onboard LEDs to freeze in their last state (including LEDs on a USB WiFi dongle). All SSH sessions are immediately hung, the cursor on the console freezes -- basically the entire kernel freezes, as far as I can tell. It does not reboot; I have to unplug it.

Without setting bcm2835_gpio_aren or bcm2835_gpio_afen I can rotate the encoders without issues. I also verified the encoders gets 3.3v, ground, and the output oscillates between ~10mV and 3.3v when rotating the motors.

This used to work, not perfectly since I don't think there are enough poles on the encoders, but it worked without crashing my Pi. However, the Pi has sat for a couple years while the project went on the back burner. I upgraded Arch Arm and ran the code as it was 2 years ago. I've also tried recompiling with the latest libs and gcc updates.

I can uncomment the edge detection code, unplug the sensors, and run the motors fine without speed control, or comment out the edge detection setup functions, connect the sensors, and run it fine without speed control. But I can't do both. The motor controller and all other aspects of the project seem fine.

  • 2
    Probably best to ask this on the dedicated bcm2835 library site. Why use aren/afen? Does it work with ren/fen? I doubt if the kernel actually supports aren/afen.
    – joan
    Sep 13, 2019 at 15:59
  • Dope -- good idea to try synchronous ren. If I do that I get a kernel stack trace! I'm beginning to think I don't have full kernel support for the BCM, like you said.
    – Nick
    Sep 13, 2019 at 18:38
  • Have a look through groups.google.com/forum/#!forum/bcm2835
    – joan
    Sep 13, 2019 at 19:41
  • So I updated my cross compile chain to the latest, still the same issue. I searched the user groups above and found this and this. People having the problem with any of the fen/ren/afen/aren functions across rPi boards. Apparently somewhere around kernel v4.14 the problem occured.
    – Nick
    Sep 15, 2019 at 3:10

1 Answer 1





to /boot/config.txt.

Previously the kernel would automatically disable interrupts when you set one of rising/falling edge detection methods but that apparently stopped happening, causing a kernel panic.

See this post for more details.

  • This worked for me with an RPi Zero W kernel 5.10.63+ using the BCM2835 C library. Note the library states this issue and also says to clear before setting rising or falling edge enable. Dec 3, 2021 at 1:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.