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 '19 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 '19 at 18:38
  • Have a look through groups.google.com/forum/#!forum/bcm2835 – joan Sep 13 '19 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 '19 at 3:10




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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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