SK6812RGBW(N) SPI: first led always green active on Orange Pi One

Hi all, I have been struggling with this issue for a while and have researched alot on this forum. But nothing seems to help.

First of all, I had this setup working correctly on my Raspberry Pi3B, all leds worked in good order. But since Raspberry's are as valuable as gold at the moment, I want to get Hyperion working on a Orange Pi One instead.

On the Orange Pi One setup:
- SPI activated and working
- USB Capture device is working nicely (not relevant to this issue though)
- SK6812RGBW(N) is powered by a 5v15A PSU.
- Orange Pi One powered by seperate PSU.

- GND's connected to eachother of course.

- Using PIN 19 as it is SPI MOSI pin on the Orange Pi.
- Changed RGB orde to GRB

All leds work ok, even the first led works, only it's green led is always on. The other 3 colors (Red/Blue/White) are working on the first led as they should. I can create any testing effect in correct colors and all.

For testing, put 5V on the data line and all leds went white, no green first led.

So all leds are in working order, just the first led get an incorrect command to always show green.

In this old thread they talk about this precise issue and changing values and compiling.
LINK

Change: uint8_t tx[num_leds*3*4+3];

To:          uint8_t tx[num_leds*3*4+6];

And change: unsigned spi_ptr=0;

To:                  unsigned spi_ptr=3;

But not what file they changed or how to recomplie it unfortunetaly, so I can't try this. They seem to already know how this works.

Another weird thing I noticed between the Raspberry and Orange Pi, is the BAUD rate for the same SK6812 strip.
Where the Raspberry works great with BAUD rate of 5900000, the Orange Pi only works with a BAUD rate between 2000000 and 4000000.
So there is a hardware different in the SPI I think between the boards?

Thank you for the links.

Is there a reason why I need to change the values inside the LedDeviceWs2812SPI.cpp file, while I use the SK6812SPI led strip? There is also a LedDeviceSk6812SPI.cpp file with the same unsigned spi_ptr=0; that can be changed.

Don't I need to change this file instead?

I've been trying to build Hyperion all day, even with the how-to it's not straight forward.

currently the build always crashes, on this:

[ 67%] Building CXX object libsrc/webserver/CMakeFiles/webserver.dir/webserver_autogen/IZWCZGADZF/qrc_WebConfig.cpp.o

[ 67%] Built target protoc

c++: internal compiler error: Killed (program cc1plus)

Please submit a full bug report,

with preprocessed source if appropriate.

See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.

libsrc/webserver/CMakeFiles/webserver.dir/build.make:398: recipe for target 'libsrc/webserver/CMakeFiles/webserver.dir/webserver_autogen/IZWCZGADZF/qrc_WebConfig.cpp.o' failed

make[2]: *** [libsrc/webserver/CMakeFiles/webserver.dir/webserver_autogen/IZWCZGADZF/qrc_WebConfig.cpp.o] Error 4

CMakeFiles/Makefile2:2588: recipe for target 'libsrc/webserver/CMakeFiles/webserver.dir/all' failed

make[1]: *** [libsrc/webserver/CMakeFiles/webserver.dir/all] Error 2

Makefile:155: recipe for target 'all' failed

make: *** [all] Error 2

It seems file qrc_WebConfig.cpp.o does not get created, I can't find it in the folder. Which would explain the error afterwards. No idea how to fix this.

I've already tried this option, also the -j 1, doesn't make any difference unfortunately.

I used Armbian 21 which runs om Ubuntu 18.04.
Also tried Armbian 23, which has Ubuntu 22.04, and all new version of all the programs. Still the error occurs on exectly the same part. Every time. I can't get past it.

Gonna try Armbian 23 on my RPi 3B, maybe I can compile on that device and tranfser it? No idea if it works like that...

I've tested RPi3B, same error at exactly the same file. This is not random any more and not a memory problem.

Even on the Raspberry with just -j 1 it still faults at the same file. This is getting way to problematic for just first led green.

Gonna tape off this led and start from led #2 or something.

This fix should be 1 change in that file, but building is way to comlicated this way

Tomasz They are....as I stated in the first post.

This is not the problem.

I have now succesfully compiled and run Hyperion.NG on a Ubuntu 18.04 VM on my home server.
How do I transfer this correctly to the Orange Pi and being able to run it there? Is this even possible?

I've been posts about a DEB file, but I can't find it on the Ubuntu machine.
CompileHowto.md doesn't say anything about transfer options of DEB file.

Docker and cross compile, I can't find any comprihensive information on this how this works or should be set up. If there are any guides, it's all about Raspberries.

Ok, I'm a step further now.

Lord-Grey it was indeed a memory issue. the 512Mb ram of the Pi with the default 256 Mb swap file were not enough by a long shot.

Increasing the swap file is the answer! I gave the swap file like 2Gb (way to much) and monitored the compile at the same file it always crashed before.
First it used up all the 300Mb ram it had left, then drained another 500+Mb of swap file (so 256Mb swap was way to small)

The build runs, I managed to get the SK6812spi working.
Change the LEDDEVICESK6812SPI.cpp file:

To:                  unsigned spi_ptr=3;

This indeed solves the first led always green state and all leds work as normal.

But.....the build is very non-stable. It crashes so many times and fast, it's unusable.

|__| DAEMON : <ERROR> Lock/unlock handler- Session bus is not connected

hyperiond: malloc.c:2401: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) | | ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

Hyperion caught signal :SIGABRT

Now I have to figure out how to solve this new problem.....

A reboot of the Pi and it works again, need to endurance test this further.

I will try if I can do that.

For now what I noticed:
- Hyperion runs pretty good after a fresh boot of the Orange Pi.
- After making a few (3-4) changes it starts to crash.
- Starting Hyperion again, it will crash on any change or immediately after running.

Only solution for now is again a Pi reboot, then it works again for longer period of time. I'm endurance testing atm.
Left it running over night, but this morning it was stuck/crashed after.

Lord-Grey Can you tell me to which file the cpp above goes when compiling?

Maybe I could install the normal 2.0.15 Hyperion-NG and just copy that 1 file with the adjusted led variable from my compiled build.
Then I would have a fixed 2.0.15 installation.

Thanks!

Copying the hyperiond "fixed" version to the installed folder, doesn't work, it wont start. Might be a problem with version I guess.

Using the CompileHowTo, this line give me the newer 2.0.16 alpha.

git clone --recursive https://github.com/hyperion-project/hyperion.ng.git hyperion

How do I change this line to get 2.0.15 stable to be downloaded here?

I tried many way to adjust the url, but none work, no repository.

The 2.0.16 alpha gives these errors:

free(): invalid pointer

Hyperion caught signal :SIGABRT

2023-04-14T17:38:48.077 |__| CORE : <ERROR> /lib/arm-linux-gnueabihf/libc.so.6(+0x27840) [0xb5879840]

2023-04-14T17:38:48.078 |__| CORE : <ERROR> /lib/arm-linux-gnueabihf/libc.so.6(+0x177e6) [0xb58697e6]

2023-04-14T17:38:48.078 |__| CORE : <ERROR> /lib/arm-linux-gnueabihf/libc.so.6(gsignal+0x7b) [0xb5878a20]

Aborted

I want to be able to git clone 2.0.15 and compile that. The ZIP file from https://github.com/hyperion-project/hyperion.ng/releases doesn't give the external depandacies, the git clone downloads. Combining these into 1 build folder, doesn't work either.

2.0.15 installation doesn't crash (that much) but the CompileHow To only gives me 2.0.16 alpha, which after adjusting the cpp file crashes a lot.

pclin This link is to 2.0.16 which I already had from the CompileHowTo guide.

I need to git clone 2.0.15 instead, to what do I change the url in de git clone to get the 2.0.15 stable realease, instead of the 2.0.16 alpha?