Running ws2812B with dead GPIO18

  • Hi,


    I'm trying to control ws2812b LEDS with a raspberry pi 2.


    I've measured ~5v power at both ends of the strip.


    I believe I burnt out my gpio18 because I ran a gpiotest which complained about that pin and I also tried using this method of setting pin output with bash: https://raspberrypi-aa.github.io/session2/bash.html


    GPIO18 shows .2V regardless of set to high or low.


    However, GPIO12 shows 3.3V or 0V when set high or low. It's also labeled as PWM0 here: https://www.raspberrypi.org/documentation/usage/gpio/


    Is is possible to use GPIO12?
    I've wired it up and changed my settings in Hyperion dashboard but I don't see any light.


    I tried changing the effect in the dashboard remote and also using boblight server with the phone app. I see the colors change in dashboard but all LEDs remain off.


    What could I be missing?


    upload_2020-12-14_19-7-21.png

  • hello,



    the pin GPIO 18 isn't broken or anything, it probably has to do with user-rights in the kernel of the PI.

  • probably this will work..


    the PI has to run as root for WS281x ledstrips


    in terminal SSH or Putty;



    Sudo nano /etc/ssh/sshd-config



    look for
    #permitRootLogin prohibit password


    change to
    PermitRootLogin no



    save and exit, after this reboot and has to work now ( i received this from a forum member that did this procedure last week)

  • I would advise NOT to do the above commands unless you use another user account to SSH into the pi, all that does is block the user root from logging in via SSH so any further access would need to be done the old fashioned way with a keyboard and mouse unless you have another user account that has SSH access.


    If its permission problems then tailing the logs and fixing the the permissions would be the best way forward, could sort of see the logic in this if o/s blocks root login by default and you need to enable it if Hyperion is running on another server but not this way round.


    Yeah you should be able to use any of these Hardware PWM pins available on GPIO12, GPIO13, GPIO18, GPIO19 instead of 18 (i use pin 12 as 18 is used on IR remote) but should be a case of changing the pin and controller type to RPi PWM in hyperion LED Hardware section an boom


    I take it Hyperion is installed locally on the pi2 controlling the strip directly on the GPIO header?


  • I agree I don’t see the purpose of disabling root but I could try it. I login with “pi” user so it shouldn’t affect me?


    yes, Hyperion is installed locally on the pi2 and leds connect directly to gpio header. The Hyperion dashboard loads on local network and when I tail the logs, there is no error when I switch to any of the GPIO pins you listed.


    I’ve also tried bypassing the first couple of leds on the data line as they can sometimes be destroyed if I did something wrong previously.


    I almost feel like there’s some “turn on” switch in Hyperion dashboard somewhere that I haven’t found yet. I have turned on effects in the Hyperion remote though so I’d assume that would work.

  • if you want to connect PWM to GPIO18 on Hyperbian then this is ( what he told me and he found out because other people have this problem) the way to redirect the root login.


    i don't need it myself, but for this type of ledstrip and setup it worked for him, while other things sorting out didn't make a diffrence.,.
    If you are doing it or not its your choice. :)

  • I just don't see the logic in it mate or how it would benefit the current situation but stranger things have happened lol. but it has the potential to break numerous default setups if the user doesn't understand what the command is doing.


    Dyaln: yeah you can try it but i dont think it will work.


    Have you tried in Configuration -> General -> LED Hardware Instance Management - Is the Instance running?


    You could add another instance, set it up on pin 12 then start it, if it works remove the others.

  • I am not running Hyperbian, I'm running Raspbian



    me too,



    you can switch between different instances by selecting the instance you want to run and then in upper right corner of the browser [with arrows <> ]
    choose your running instance, dot is turning into green then (active)



    goodluck.

  • note#


    with a second running instance that you made its not possible to control that instance with the Hyperion app.
    Only the first instance is to be controlled by the app by default in the Hyperion program.



    so that you know, and not wondering why remote control on the app isn't working with second instance enabled. :)

  • lol jeroen I was mid reply with the instance bit :)


    Just to confirm as you never really mentioned, have you ever had the lights working? or did something go wrong with them at some point and you suspect you burnt out gpio pin18 as a result of it.


    Is it a fresh install thats thrown problem after problem or was it smooth sailing?


    whats in your /boot/config.txt?

  • you can do a GPIO test



    Troubleshooting
    Loopback test
    This can be used to test SPI send and receive. Put a wire between MOSI and MISO. It does not test CE0 and CE1.


    wget https://raw.githubusercontent.…ntation/spi/spidev_test.c
    gcc -o spidev_test spidev_test.c
    ./spidev_test -D /dev/spidev0.0
    spi mode: 0
    bits per word: 8
    max speed: 500000 Hz (500 KHz)


    FF FF FF FF FF FF
    40 00 00 00 00 95
    FF FF FF FF FF FF
    FF FF FF FF FF FF
    FF FF FF FF FF FF
    DE AD BE EF BA AD
    F0 0D



    example of output after command, source https://www.raspberrypi.org/do…raspberrypi/spi/README.md

  • SPI Function Header Pin Broadcom Pin Name Broadcom Pin Function
    MOSI 19 GPIO10 SPI0_MOSI
    MISO 21 GPIO09 SPI0_MISO
    SCLK 23 GPIO11 SPI0_SCLK
    CE0 24 GPIO08 SPI0_CE0_N
    CE1 26 GPIO07 SPI0_CE1_N

  • @davieboy I previously had these same LEDs working on the same pi. I accidentally crossed some wires and the pi fuse blew out. It didn't turn back on for two days.


    So when it booted up again I couldn't get things to work and figured I'd upgrade to the latest version of hyperion.


    Boot config seems mostly commented:
    ```
    # 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=on
    #dtparam=i2s=on
    #dtparam=spi=on
    # Uncomment this to enable the lirc-rpi module
    #dtoverlay=lirc-rpi
    # Additional overlays and parameters are documented /boot/overlays/README
    # Enable audio (loads snd_bcm2835)
    dtparam=audio=on
    dtparam=spi=on
    ```


  • @jeroen warmerdam I tested GPIO with instructions here: https://www.raspberrypi.org/forums/viewtopic.php?t=180505


    My results were:
    Testing...
    Write 1 to gpio 17 failed.
    Pull up on gpio 17 failed.
    Write 1 to gpio 18 failed.
    Pull up on gpio 18 failed.
    Skipped non-user gpios: 0 1 28 29 30 31
    Tested user gpios: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
    Failed user gpios: 17 18


    So this makes me think GPIO 12 should still be good.




  • ?? you have two counter settings in here,
    first you say with commenting the hardware device is OFF #example is OFF!
    then you say in last line that uncommenting dtparam=spi=on is ON!



    delete that last line and uncomment all hardware interfaces, no harm no faul.

  • @dylan.



    you didn't uncomment anything in the file so the whole config.text is basic and has no settings you alternated.


    sure you know what you are doing guy?

  • +1 Jeroen - sure you know what you are doing guy?


    Yeah no need to touch the config everything except the last 2 lines are ignored.


    The way I see it, you have 1 out of 3 things
    1- Fried Pi
    2- Fried LED Strip
    3- Bad setting somewhere


    Id do the quick and easy one first and pull the SD card and put 1 in that has Hyperbian image on it just for ease of use and see if you can get the leds to light up on GPIO12, if no joy after that id look to try and power the LEDS another way to see if they are working, then move onto the pi, but you cant really use a multimeter on the PWM pins, ideally you'd want to scope them and check the wavelength pattern as the meter is too slow to check it.


    If i was to hazard a guess id put money on the pi being fried, but ill keep my fingers crossed for you that its only a bad setting somewhere and hopefully a fresh flash of Hyperbian will solve it.


    Good Luck

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!