GPIO (using sysfs problem)

Question

I'm presently trying to use the built-in indicator lights on the Raspberry Pi B+ to provide status: Green = OK; Red = Problem

After turning off the triggers (writing none to /sys/class/leds/led[0,1]/trigger) I update the LED using the following java code:

    FileWriter fw = new FileWriter(brightnessFile);
    String writeString = isOn?"255":"0";
    fw.write(writeString);
    fw.close();

However, I am noticing situations where the program has written 255 to the brightness file (e.g. /sys/class/leds/led0/brightness ) but the LED is not illuminated. Similarly, if I read the value from /sys/class/leds/led0/brightness, it doesn't appear to correspond to the current status of the LED. E.g. the LED is not illuminated, but the value read from /sys/class/leds/led0/brightness is 255, etc.

Sometimes after seeing the issue, I might do the following in the shell:

sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
sudo bash -c 'echo 255 > /sys/class/leds/led1/brightness'

which results in led1 going on, but led0 remains off (?!)

Alternating values seems to help however:

sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'

Is this a known bug? Is there a better way? - The more I read about pi4j (which also doesn't seem to support the onboard LEDs easily) and wiringPi, it appears that they use sysfs, which (correct me if I am wrong) would seem to be no different from what I am doing here. In addition to not being reliable, this method seems very slow.

Speculating to possible causes:

• SD Card Wear (e.g. if the /sys/ filesystem also maintains a presence on the boot volume)
• Power Supply (seems to be the most common answer to any kind of weird problem)
• Hardware Damage (I will try with another board to see if I get the same thing)

Strangeness Examples:

pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255
pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 255 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
0

(Not Okay)

pi@pitv:~ $ sudo bash -c 'echo 0 > /sys/class/leds/led0/brightness'
pi@pitv:~ $ cat /sys/class/leds/led0/brightness
255

(Not Okay)

Just to illustrate that there is no other trigger interfering:

pi@pitv:~ $ cat /sys/class/leds/led0/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd- altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on input panic mmc0 mmc1 rfkill0 rfkill1 
pi@pitv:~ $ cat /sys/class/leds/led1/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu0 cpu1 cpu2 cpu3 default-on input panic mmc0 mmc1 rfkill0 rfkill1 

Answer 1

You are wasting your time trying to control the on-board LEDs.

They are controlled by kernel services, and additionally for the Red LED a hardware power monitor.

You CAN change their state, but the kernel will change them independently on its own schedule.

You can modify their behaviour, to a limited extent, by setting up the appropriate configuration in Device Tree.