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.