BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

Ich bin ja gerne bereit, bezüglich WLAN weiter zu testen und meine Erkenntnisse zu teilen.

Aber kannst Du mir bitte dabei helfen, eine platformio.ini zu finden, mit der ich die Software so kompilieren kann, dass sie zumindest läuft und nicht in einer Boot-Schleife endet? Da scheint es offenbar noch Probleme zu geben, die nichts mit WLAN zu tun haben dürften.

Mit dem Eintrag, der aktuell für C5 auf github steht, scheint das nicht zu klappen. Auch die Änderungen nach Deinen Hinweisen im vorletzten Beitrag haben keinen Erfolg gebracht.

[tostmann]

Moin,

deine Trennung stimmt: die Boot-Schleife ist ein Config-/Board-Mismatch, nicht WLAN. Unser env:c5 ist bewusst auf ein nacktes 4-MB-Board OHNE PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv, flash_size 4MB) — kein BOARD_HAS_PSRAM, kein psram_type, kein flash_mode. Dein DevKit ist ein N16R8, also 16 MB Flash + 8 MB PSRAM; genau diese Config auf einem PSRAM-Board crasht deshalb beim Boot.

Zwei Wege:

1. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

2. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

Code Auswählen Erweitern

[env:c5-16mb]           ; UNGETESTET — guess fuer C5 N16R8 (16 MB Flash + 8 MB PSRAM)
extends = common
board = esp32-c5-devkitc1-n4
board_upload.flash_size = 16MB
board_build.partitions = partitions.csv          ; 16-MB-Layout, wie env:s3
board_build.filesystem = littlefs
; C5-PSRAM = QUAD-SPI (NICHT Octal wie S3!) -> qspi, nicht opi:
board_build.arduino.memory_type = qio_qspi
board_build.psram_type = qspi
build_flags =
    ${common.build_flags}
    -D ARDUINO_USB_MODE=1
    -D ARDUINO_USB_CDC_ON_BOOT=1
    -D BOARD_HAS_PSRAM
    -D SIXBACK_SPOTIFY_ENABLED=1
    -D SIXBACK_OTA_ENABLED=1
    -D SIXBACK_OTA_PREFIX='"sixback-c5-"'

Wenn der Boot damit durchläuft: der serielle Backtrace direkt nach einem Reboot sagt sofort, ob es noch am PSRAM/Heap hängt. Und falls es weiter zickt, ist Weg 1 der verlässliche.

Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Gruß

[betateilchen]

Ein Stück weiter bin ich inzwischen.
Ich habe den Abschnitt vom simplen ESP32 kopiert und angepasst.

Code Auswählen Erweitern

[env:c5]
extends = common
board = esp32-c5-devkitc1-n4
board_build.partitions = partitions-4mb.csv
board_build.filesystem = littlefs
board_upload.flash_size = 4MB
; FS-Image filtern: silence.mp3 (Spotify-only, ~120KB) raus, sonst sprengt das
; data/-Payload (244KB) das 256KB-spiffs der 4mb-OTA-Tabelle -> LFS_ERR_NOSPC.
; Classic hat kein Spotify, braucht silence.mp3 nicht. version_bump.py bleibt.
extra_scripts =
    ${common.extra_scripts}
    pre:scripts/fs_exclude_esp32.py
build_flags =
    ${common.build_flags}
    ; ESP32-classic behaelt A/B-OTA (1.81MB Slots reichen)
    -D SIXBACK_OTA_ENABLED=1

Damit komme ich bis hierhin:

Code Auswählen Erweitern

14:27:32.527 >
14:27:32.527 > =========================================
14:27:32.527 >   SixBack 0.8.27+1700
14:27:32.527 >   Build: 2026-07-01 14:23:31
14:27:32.527 >   Copyright (c) 2026 Dirk Tostmann
14:27:32.539 >   License: PolyForm Noncommercial 1.0.0
14:27:32.539 >   Commercial use prohibited — see LICENSE
14:27:32.539 > =========================================
14:27:32.550 > [mbedtls] PSRAM not available — keeping default internal allocator
14:27:32.550 > [fs]   LittleFS mounted, 8192/262144 bytes used
14:27:32.550 > [   549][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.580 > [   584][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.590 > [uiauth] web-UI password protection disabled
14:27:32.590 > [   590][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [   600][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [improv] starting (idle-window 120s, no NVS-creds present)
14:27:33.255 > [  1259][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:33.261 > [provision] improv-exclusive window 10s (no captive yet)
14:27:43.266 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:43.266 > [provision] no NVS connect — waiting on improv OR captive

Das sixback-WLAN ist da, das Portal kommt, aber das war es dann auch.
Der Scan liefert kein Ergebnis, ein manuelles Eintragen der Daten auf der Portalseite funktioniert auch nicht.
Es kommt immer noch die vom watchdog ausgelöste Reboot-Schleife.

Code Auswählen Erweitern

14:27:10.658 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:10.670 > [provision] no NVS connect — waiting on improv OR captive
14:27:31.101 > E (32670) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
14:27:31.101 > E (32670) task_wdt:  - async_tcp (CPU 0)
14:27:31.112 > E (32670) task_wdt: Tasks currently running:
14:27:31.112 > E (32670) task_wdt: CPU 0: IDLE
14:27:31.112 > E (32670) task_wdt: Aborting.
14:27:31.120 > E (32670) task_wdt: Print CPU 0 (current core) registers

Wie bekommt man das NVS Problem in den Griff?
Müsste das nicht automatisch beim Start formatiert werden, wenn es noch nicht existiert?

[betateilchen]

Wir haben wohl gerade beide eine Antwort geschrieben...

1. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

2. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

Das werde ich testen, danke.

Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Genau darum geht es mir, ich möchte zumindest mal bis zur Möglichkeit kommen, das WLAN überhaupt zu testen. Und dann kann ich weiter forschen.

[betateilchen]

Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

Ok, ich habe jetzt bei Aliexpress bestellt.
Versand + Zölle sind seit heute höher als der Artikelpreis...

[tostmann]

ich hatte seinerzeit den bestellt:

https://de.aliexpress.com/item/1005010442802432.html

Krass, jetzt 4 Euro teuer ...

[betateilchen]

ich habe den hier bestellt: https://de.aliexpress.com/item/1005012416463528.html

[tostmann]

SixBack v0.8.28 ist raus — ESP32-C5-Support (Dual-Band/5 GHz) + Fixes am WLAN-Setup

Der ESP32-C5 ist ab dieser Version ein offizielles Target: Der Web-Flasher auf https://sixback.io/ erkennt den Chip automatisch, OTA-Kanal inklusive. Verifiziert haben wir auf zwei C5-Boards (die verbreiteten 4-MB/N4-DevKitC-Klone): beide Provisioning-Wege — Captive-Portal und Improv über den Web-Flasher — enden dort in einer 5-GHz-Verbindung, die Zugangsdaten überleben den Reboot.

Beim C5-Testen haben wir auch die Ursache für die hier gemeldete Reboot-Schleife während des Portal-Setups gefunden: Der WLAN-Scan lief bisher blockierend im Webserver-Task. Auf Dual-Band-Chips dauert der Scan über beide Bänder rund 9 Sekunden — das reißt den 5-Sekunden-Task-Watchdog, und der Stick macht einen Panic-Reboot genau in dem Moment, in dem die Setup-Seite lädt (die Seite stößt den Scan automatisch an). Bei jedem neuen Versuch dasselbe. Auf reinen 2,4-GHz-Chips blieb derselbe Code mit ~4 Sekunden knapp unter der Grenze, deshalb ist das erst mit dem C5 aufgefallen. Der Scan läuft jetzt asynchron; auf unseren C5s war der Crash vorher zuverlässig reproduzierbar und tritt seit dem Fix nicht mehr auf.

Weitere Fixes am Setup-Fluss in v0.8.28: Das Portal-Fenster ist jetzt idle-basiert (5 Minuten seit der letzten Interaktion, 30 Minuten Obergrenze) statt eines harten 5-Minuten-Abbruchs, der auch mitten in der Passwort-Eingabe zuschlagen konnte. Ein laufender Verbindungsversuch wird am Fensterende nicht mehr abgebrochen (vorher konnten korrekt eingegebene Zugangsdaten dabei verloren gehen). Nach erfolgreichem Setup startet der Stick einmal neu — vorher konnte die Web-UI auf Port 80 bis zum nächsten Reboot unerreichbar bleiben, was wie ein fehlgeschlagenes Setup aussah, obwohl der Stick längst im WLAN war. Und auf der Improv-Seite: serielle Daten nach Ablauf des Improv-Fensters können ein unprovisioniertes Gerät nicht mehr dauerhaft lahmlegen; es kehrt immer in seinen Setup-Zyklus zurück.

Für alle, die aus den Quellen bauen: Der Verweis auf die Improv-Bibliothek zeigte auf einen Commit, den es im öffentlichen Repo nicht mehr gab — frische Checkouts schlugen deshalb beim Bauen fehl. Ist ebenfalls behoben, ein frisches Clone+Build geht wieder durch.

@betateilchen: Dein N16R8 müsste vom Scan-Fix direkt profitieren — der Crash-Mechanismus ist board-unabhängig, und Dein Fehlerbild (Reboot-Schleife, sobald das Portal bedient wird) passt exakt darauf. Getestet haben wir allerdings nur die 4-MB/N4-Variante; das c5-Build ist auf 4 MB Flash ohne PSRAM ausgelegt und läuft auf größeren Boards im 4-MB-Layout (ein eigenes 16-MB/PSRAM-Target steht noch aus). Wenn Du v0.8.28 auf Deinem Board probierst, wären Deine Ergebnisse sehr willkommen.

Update wie gewohnt: OTA über die Web-UI oder komplett frisch über https://sixback.io/. Die Partitionslayouts sind unverändert, OTA ist also für alle Targets unkritisch. Changelog: https://github.com/tostmann/SixBack/releases/tag/v0.8.28