Der Crash kommt aus dieser Zeile:
Also bei der Freigabe der alten Playlist Hat jemand eine Idee?
Ist es denn reproduzierbar diese Stelle? Könnte auch ein memory -leak wo anders sein, dass halt in diesem Fall den string mit der Nummer korrupiert (und damit den Crash auslöst)…
Wie schnell kannst du das reproduzieren und hast du ein Gefühl was als Vorbereitung herrschen muss, damit den Crash kommt?
Das ging ziemlich schnell nach dem flashen. Kurz Karten probiert, schon war der Crash. Ich kann das aber heute Abend nochmal testen und schauen wie die Meldung dann aussieht.
Ich hatte auch Probleme mit Verzeichnissen die Umlaute im Namen hatten, dort musste ich den Namen ändern und neu zuweisen.
Ich habe es nun nach einem erneuten flashen nochmals probiert und konnte den Fehler nicht reproduzieren. Also falscher Alarm. Jedoch habe ich ein Problem mit dem Wakeup aus dem Deepsleep. Dieser klappt nicht.
Mit den gleichen Settings im Master klappt es. Jemand eine Idee?
Habe die Mini 4L mit D32 Pro.
Das einzige Mal wo ich dieses Phänomen hatte war es weg, nachdem ich das Board einmal völlig stromlos geschaltet habe. Das ist aber schon ne ganze Weile her.
Für die Zukunft habe ich im Logging die Ausgabe des freien Heap vor der Freigabe der Playlist eingebaut. Evt. kann man das Problem dann besser erkennen:
[69744] Gebe Speicher der alten Playlist frei (Freier Speicher: 48880 Bytes)
2 „Gefällt mir“
Um die Bootzeit/Startvorgang zu verkürzen haben wir ja schon die PSRAM Prüfung hier ausgeschaltet. Jetzt habe ich dieses IDF-Beispielprojekt gefunden:
# at risk of not detecting flash corruption, skip bootloader
# verification of the app unless a soft reset or crash happened
#
# note: the larger the application, the bigger the time saved by
# from this option
CONFIG_BOOTLOADER_SKIP_VALIDATE_ON_POWER_ON=y
Damit wird die Flash Speicherprüfung ausgeschaltet. Hab’ jetzt keine genaue Messung aber mein ESP-32 scheint damit deutlich schneller hochzufahren. Ist das ein Kandidat für uns oder kommen wir da in eine „Dangerzone“?
Espressifs Doku sagt dazu:
Setting CONFIG_BOOTLOADER_SKIP_VALIDATE_ON_POWER_ON skips verifying the binary on every boot from the power-on reset. How much time this saves depends on the binary size and the flash settings. Note that this setting carries some risk if the flash becomes corrupt unexpectedly. Read the help text of the config item for an explanation and recommendations if using this option.
Und weiter:
Some applications need to boot very quickly from power on. By default, the entire app binary is read from flash and verified which takes up a significant portion of the boot time.
Enabling this option will skip validation of the app when the SoC boots from power on. Note that in this case it’s not possible for the bootloader to detect if an app image is corrupted in the flash, therefore it’s not possible to safely fall back to a different app partition. Flash corruption of this kind is unlikely but can happen if there is a serious firmware bug or physical damage.
Following other reset types, the bootloader will still validate the app image. This increases the chances that flash corruption resulting in a crash can be detected following soft reset, and the bootloader will fall back to a valid app image. To increase the chances of successfully recovering from a flash corruption event, keep the option BOOTLOADER_WDT_ENABLE enabled and consider also enabling BOOTLOADER_WDT_DISABLE_IN_USER_CODE - then manually disable the RTC Watchdog once the app is running. In addition, enable both the Task and Interrupt watchdog timers with reset options set.
Ich glaube ich würde das bestehen lassen. Seit Arduino2 geht, auch bei WROVER, der Bootvorgang doch echt sau schnell.