Invalid header after flashing firmware

[amigthea]

after I flash the .bin and I try to connect to serial port it outputs continuosly this log:

st:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20
invalid header: 0x28202b20

it is expected?

[awawa-dev]

no
more details: which firmware, board model etc

[amigthea]

Platform: ESP32 MH-ET Live

I followed the wiki instructions:

• Forked
• Edited the platformio.ini (only the build_flags line)

[env:SK6812_RGBW_NEUTRAL]
build_flags = -DNEOPIXEL_RGBW -DDATA_PIN=2 ${env.build_flags} -DSECOND_SEGMENT_START_INDEX=112 -DSECOND_SEGMENT_DATA_PIN=4 -DSECOND_SEGMENT_REVERSED
custom_prog_version = esp32_SK6812_RGBW_NEUTRAL

board = esp32dev
platform = ${esp32.platform}
lib_deps = ${esp32.lib_deps}
test_ignore = ${esp32.test_ignore}

• flashed the firmware

./esptool write_flash 0x0 firmware_esp32_SK6812_RGBW_NEUTRAL.bin

• it gives those errors

[awawa-dev]

You flashed the firmware at wrong address and damaged the bootloader. Use factory firmware:
https://github.com/awawa-dev/HyperSPI?tab=readme-ov-file#flashing-the-firmware

[amigthea]

ok, now I flashed the factory firmware and then the custom one at the correct address

./esptool write_flash 0x0 firmware_esp32_SK6812_RGBW_NEUTRAL.factory.bin
./esptool write_flash 0x10000 firmware_esp32_SK6812_RGBW_NEUTRAL.bin

and now it does not gives me those error anymore

but even if I configured the Led Hardware section as shown by the guide I get

[LEDDEVICE0_AWA_SPI] Device 'awa_spi' is disabled due to an error: 'Failed to open device (/dev/spidev0.0). Error message: No such file or directory'

tried to change that to /dev/ttyACM0 to no avail, what could be the cause?

edit: the controller is usb connected to the rpi4 where HyperHDR is running

[awawa-dev]

/dev/spidev0.0 must be activated in the system first, usually HyperHDR installer tries to enable it but it requires a restart. Use raspi-config alternatively.

[amigthea]

thank you, that solved the Led Hardware recognition problem <3

I have the Video Capturing configuration up and running (confirmed by the Live Video preview) but both led segments are off and they do not turn on, and I'm trying to solve this. From a soldering perspective I have this exact scheme from the controller to the ledstrip and the wiring show here from the controller to the rpi4, is that missing something, maybe another wire to the raspberry while using two segments?

If the wiring is ok, what could keep the leds off?

[awawa-dev]

Make sure that there is communication first (sometimes users use very strange or long wiring to connect Rpi to ESP SPI or they forget about ground which is mandatory and as important as other SPI cables) https://github.com/awawa-dev/HyperSPI?tab=readme-ov-file#performancedebug-output
run screen => run HyperHDR and some effect using configured SPI devices => stop HyperHDR => screen should show some statistics

both segments must be equal and total number of LEDs in HyperHDR = 2 * size of the segment

[amigthea]

first of all, I wanna thank you for the patience you're showing to my non-optimal interaction, I will be more specific in my communication.

After some trial, I triple checked everything and I think the problem resides in the controller itself; maybe it's the wrong model? I bought this one and esptool read_mac gives me

Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)

ps: I already bought another batch, this time I ordered the model you suggested in another discussion.

Could this be the problem?

[amigthea]

update: visually inspecting the board I found the chip type ingraved on a little black chip, it's the CH9102F, is that chip usable in this project or I need the CH9102X (that I bought meanwhile)?

[awawa-dev]

The serial chip is not important in the HyperSPI project because we only use it for diagnostics, taking advantage of the low speed that any such chip can handle. You must have a correct SPI connection (including ground) and screen must confirm SPI communication and that frames are reaching from RPi to ESP32. You can test it without LEDs connected.

[amigthea]

thank you so much! I was able to pinpoint the problem, something went wrong when forking the project/creating the custom firmware. Now everything works, almost perfectly.

I have one last problem with the video capture source: even in the blackest scenes, the leds emit a dim light and do not completely turn off.

• If I select a fixed color source rgb(0,0,0) they turn off correctly.
• HDR to SDR tone mapping is disabled (but I should enabled it because I get this problem with DV content)

What could cause that?

this is a screenshot from the video grabber, o a completely black scene, taken from Live video menu.

[awawa-dev]

set minimal backlight to 0 in the processing tab

[amigthea]

is 25-30cm considered a long wiring?
I have the ground from one of the segments all way down to the rpi, passing through the level shifter and the controller. The 5v of the same segment splits to the power supply and to the level shifter. The second segment has only the data cable connected to the level shifter, its 5v and gnd are connected to the power supply only, could that be a problem?

[amigthea]

I have some other doubt on the controller too, is this the right one (ESP32 D1 MINI) ?

Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)