Es können keine neuen Karten mehr zugewiesen werden / nvs voll

Hallo zusammen,

ich habe vorgestern meinen ersten Espuino fertig zusammen gebaut (Bilder folgen noch) und bin nun dabei ihn zu bespielen. Ich habe laut backup.txt nun 86 Alben/Hörspiele jeweils einer Karte zugewiesen. Allerdings kann ich jetzt keine weitere Karte mehr zuweisen. Die Web-Oberfläche erkennt den Tag, wenn ich auf „Absenden“ gehe, es erscheint jedoch nicht wie sonst die Bestätigungsnachricht.

Im Monitor sehe ich nun folgende Ausgabe:

nvs_set_str fail: 083037076178 NOT_ENOUGH_SPACE

Der nvs scheint also voll zu sein.

Der Espuino nutzt ja das Partitionsschema huge_app.csv (arduino-esp32/huge_app.csv at 8dc70e0add06e75da5a255ba94fe86df98ae5ef1 · espressif/arduino-esp32 · GitHub). Wenn ich es richtig verstehe, ist hier für nvs 21 000 Byte (20KB) vorgesehen. Sehe ich das richtig? (Die Datei backup.txt ist allerdings 7,79KB groß.)

Falls mein Verständnis richtig ist: Die Partition für nvs sollte man mit einem eigenen Partitionsschema größer machen können, oder?

Und noch eine kurze Frage: Wenn ich in VS Code im PlatformIO Plugin auf „Upload“ gehe, werden dann die Partitionen auf dem Esp32 automatisch geändert?

Viele Grüße,
Alex

Moin.

Oh, dann brauchen wir wohl eine Custom-Partitionierung. Ich hatte mir die Werte nicht angeschaut wenn ich ehrlich bin. Vielleicht nimmt man besser 100k.
Zur anderen Frage: Habe zumindest nie was Anderes gemacht.
https://docs.platformio.org/en/latest/platforms/espressif32.html#partition-tables

Ich weiß jetzt nur gerade nicht, wo man das selbst gestrickte File dann ablegen muss.

Vielen Dank für die schnelle Antwort. Ich schaue mir das Thema an sobald ich Zeit habe.

Hallo zusammen,

man kann die selbst erstellte Partitions-Datei direkt im Root speichern und diese dann in der platformio.ini angeben. Man sollte nur einen Datei-Namen wählen, welcher nicht den mitgelieferten Partitions-Dateien gleicht. Zum Beispiel:

board_build.partitions = custom.csv

Viele Grüße
Martin

1 „Gefällt mir“

Danke für deine Info. Wieder was gelernt :+1:

Unter Linux liegen die Dateien unter ~/.platformio/packages/framework-arduinoespressif32/tools/partitions.
Das ist das versteckte Platformioverzeichnis.
Findet man aber schnell, wenn man nach z.B. huge_app.csv sucht.

1 „Gefällt mir“

Ich habe mich gerade an diesem Thema versucht. Ausgehend von der Partitionstabelle huga_app.csv habe ich zunächst die Partition von app0 verkleinert, um Platz für die Partition nvs zu bekommen. Das hat auch so weit funktioniert und der Espuino startet. Die Tabelle schaut dann so aus:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,           ,  0x2000,
app0,     app,  ota_0,         ,  0x210000,
spiffs,   data, spiffs,        ,  0xF0000,

Wenn ich jetzt allerdings versuche die Größe der Partition vns zu erhöhen, startet der Espuino dann nicht und bootet ständig neu. Die folgende Fehlermeldung erscheint sehr häufig nacheinander auf der Konsole:

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
ets Jun  8 2016 00:22:57

Ausprobiert habe ich z.B. folgende Partitionstabelle. Die Größe der Partition nvs ist hier doppelt so groß wie in huge_app.csv.

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0xA000,
otadata,  data, ota,           ,  0x2000,
app0,     app,  ota_0,         ,  0x210000,
spiffs,   data, spiffs,        ,  0xF0000,

Ich hatte mich übrigens vertan, was die Größe der Parition nvs im Partitionsschema huge_app.csv anbelangt. Es sind 21.000 Byte anstatt 5.000 Byte. Ich habe es oben im ersten Beitrag korrigiert.

So sieht Huge App in Bytes aus:
20480
8192
3145728
983040
‭Summ: 4.157.440‬

So sieht deines in Bytes aus:
40960
8192
2162688
983040
‭Summe: 3.194.880‬

Hast du da extra so viel verschenkt? Konkret frage ich mich, ob die app0 nicht (nen Tick) zu klein ist. Wobei eigentlich sollte es dann schon zu einem Fehler beim Flashen kommen.

Mir ist aber ehrlich gesagt nicht so ganz klar, was es mit dem Offset auf sich hat. Vielleicht weiß das hier jmd!?

Das war erstmal nur zum Ausprobieren. Zuerst hatte ich den gesamten Platz, den ich bei app0 weggenommen habe nvs zugewiesen. Das sah dann so aus:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0xF5000,
otadata,  data, ota,           ,  0x2000,
app0,     app,  ota_0,         ,  0x210000,
spiffs,   data, spiffs,        ,  0xF0000,

Da das aber nicht ging, habe ich erstmal in kleinen Schritten versucht Änderungen vorzunehmen.
Zunächst habe ich die app0 Partition verkleinert, das hat funktioniert. Danach habe ich nvs erstmal nur verdoppelt um zu sehen, ob das überhaupt geht. Das hat aber leider nicht funktioniert.

Am liebsten würde ich nvs dann so viel zuweisen, wie geht. Auch andere Größen für nvs habe ich ausprobiert.

Die Partition app0 ist in meinem Fall nicht zu klein. Ich habe allerdings auch einige Features wie MQTT nicht aktiviert. Mit der ersten Partitionstabelle mit verkleinerter app0 Partition (siehe oben) läuft der Espuino auch.

Ah, jetzt verstehe ich deinen Post :slight_smile:
Sorry, hatte es wohl nicht richtig gelesen.
Ja, 2.1 MB können reichen, aber da wird es schon eng aktuell. Zur Problematik kann ich leider nix beitragen. Custom-Partition hatte ich noch nicht.

Mit dem vergrößerten NVS kannst du dann mehr Karten anlernen? D.h. es klappt dann wie gewünscht?

Nein, leider nicht, da das Vergrößern des NVS bisher noch nicht geklappt hat.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/nvs_flash.html

if an NVS partition is truncated (for example, when the partition table layout is changed), its contents should be erased. ESP-IDF build system provides a idf.py erase_flash target to erase all contents of the flash chip.

Hmm. Also verkleinert hast du es ja nicht. Es ist allerdings so, dass die Daten im NVS in Namespaces liegen. Für RFID habe ich da einen eigenen. Weiß nicht, ob da noch was angepasst werden muss :thinking:

Das habe ich noch gefunden:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/nvs_partition_gen.html
Aber vermutlich wird das automatisch von Platformio aufgerufen.

Was meinst du mit „Für RFID habe ich da einen eigenen“?

Ich habe dein Eindruck, dass es nur funktioniert, wenn der Offset der Partition app0 bei 0x10000 liegt. Denn folgendes funktioniert nun bei mir:

# Name,   Type, SubType,  Offset,  Size, Flags
app0,     app,  factory, 0x10000,  0x210000,
nvs,      data, nvs,            ,  0x80000,

Ich habe hier die Partition nvs nach app0 angeordnet und die anderen beiden Partitionen entfernt.

Wenn ich allerdings als Offset für app0 0x20000 wähle, funktioniert es nicht und der Espuino startet die ganze Zeit neu. Laut Dokumentation sollte das jedoch auch funktionieren:

Partitions of type app have to be placed at offsets aligned to 0x10000 (64K). If you leave the offset field blank, gen_esp32part.py will automatically align the partition. (Partition Tables - ESP32 - — ESP-IDF Programming Guide latest documentation)

Den Flash zu löschen hatte ich auch schon ausprobiert. Aber danke für den Hinweis :slight_smile:

Da siehst du, dass die RFIDs in einem eigenen Namespace leben. Die ganzen Settings leben in ihrem eigenen.

@biologist Vielen Dank für die Erklärung :slight_smile:

Ich habe meinen Espuino nun mit folgender Partitionstabelle konfiguriert:

# 192KB for nvs, the rest is for the application
# Name,   Type, SubType,  Offset,  Size, Flags
app0,     app,  factory, 0x10000,  0x3C0000,
nvs,      data, nvs,            ,  0x30000,

Ich konnte das Backup der bisherigen Kartenzuweisungen einspielen und habe nun etwa 20 weitere Karten zugewiesen. Es scheint also nun zu funktionieren. :slight_smile:

Mir ist dabei übrigens noch aufgefallen, dass die Umlaute in der backup.txt nicht korrekt dargestellt werden. Das Einspielen des Backups funktioniert dennoch und die Ordner mit Umlauten sind anschließend korrekt mit den Ordnern verknüpft.

Falls jemanden die genauen Änderungen interessieren, sind diese hier zu finden: Custom partition table with 192KB for nvs. The partition table huge_a… · AlexBoehm/ESPuino@34dd014 · GitHub

1 „Gefällt mir“

Das wird ein Problem mit der Zeichenkodierung deines Editors sein. Der wird die Datei vermutlich als utf8 oder iso-8859-1 öffnen und dann passt das nicht. Mit cp437 sollte es passen. Das Thema ist so ein bisschen schwierig. Weil du kannst Files ja via ftp, via Web und direkt (einstecken der SD-Karte in den Computer) übertragen. Im letztgenannten Fall können wir das Encoding nicht beeinflussen - es ist cp437 (@Christian und @Harry haben das alles ausprobiert). Deswegen mussten wir für FTP und Web dann auch auf diesen Zeichensatz gehen.

Ansonsten: Danke für deine Infos. Ich werde dann auch mal einen Custom-Table aufnehmen. Ich weiß jetzt nur nicht, was ich mit OTA machen muss. Also dieses Feature wird ja immer mal angefragt. Vielleicht wird der Spaceim Flash aber auch gar nicht gebraucht, wenn man das File via SD per OTA aufspielt.

Danke für die Info. Ich hatte die Datei mit Notepad++ geöffnet. Bei der Kodierung habe ich dort nun OEM 852 ausgewählt. Jetzt werden die Dateinamen korrekt angezeigt. :slight_smile:

Zur Partitionstabelle:
Vielleicht wäre es nicht verkehrt das Schema Huge App etwas abzuändern, aber alle Partitionen beizubehalten. Dann sollte ja auch OTA nichts im Weg stehen, oder?

Ich weiß halt ehrlich gesagt nicht so genau, was es für OTA braucht. Also normalerweise läuft das glaube ich so, dass man das hochlädt (per WLAN) - vermutlich landet es dann im Flash (als File). Und von dort wird es dann geflasht. Dieser Weg würde, abgesehen von ESP32-WROVER mit mehr Flash-Speicher, so bei uns auch eh nicht klappen, da das Image viel zu groß ist. Aber ggf. braucht es die OTA-Partition überhaupt nicht, wenn man das File eh von SD holt.

EDIT: Du hast in deinem neuen Layout aber Einstellungen erneut machen müssen (WLAN etc pp), oder? Weil NVS würde ja komplett überschrieben worden sein.
Und noch eine Frage: Mit welchen Webbrowser hast du den Re-Import gemacht?

Du hast in deinem neuen Layout aber Einstellungen erneut machen müssen (WLAN etc pp)?

Ich habe vorsorglich den Flash gelöscht. Kann also nicht sagen, ob es notwendig gewesen wäre.

Mit welchen Webbrowser hast du den Re-Import gemacht?

Mit Chrome unter Windows

Für OTA braucht man mindestens 3 Partitionen:

  • otadata: Hier die steht die Info, welche App-Partition gestartet werden soll
  • ota_0: Erste Partition für eine Applikation
  • ota_1: Zweite Partition für eine Applikation

Bei einem OTA-Update wird die neue Applikation auf die unbenutzte ota_x-Partition geflasht und dann über die otadata-Partition die Informationen hinterlegt, dass ab sofort von der neu geflashten ota_x-Partition gestartet wird. Bricht das Update aufgrund eines Fehler ab, dann wird weiterhin von der bisherigen ota_x-Partition gestartet. Dieser Mechanismus stellt sicher, dass immer eine vollständige funktionierende Applikation vorhanden ist.

Der große Nachteil bei diesem Mechanismus ist der Platzbedarf. Beide ota_x-Partitionen müssen gleich groß sein. Bei dem aktuellen Feature-Umfang sind daher 4MB Flash mit OTA etwas knapp. Die WROOM- und WROOVER-Module gibt es auch mit 16MB Flash. Leider werden bei den Dev-Boards oftmals nur 4MB Flash verbaut.

1 „Gefällt mir“