Malefici ESP32!

[pusillus]

Ciao a tutti!
E' da parecchio tempo che non apro un nuovo thread.
Da qualche tempo sto trafficando con gli ESP32 con ESP-IDF ...no Arduino!
ho realizzato un sistema con questa topologia. Ovviamente molto basico date le mie competenze.

Funzionava tutto fino a che non mi è venuto in mente di fare gli upgrade del firmware con OTA sui nodi.
Mi trovo in un circolo vizioso e non riesco a venirne fuori. Il gateway fonziona egregiamente, mentre i nodi vanno in crash durante gli upgrade. le ho provate tutte ma non riesco a venirne a capo.
Volevo sapere se qualcuno conosce bene questi SoC e se aveva voglia di dare uno sguardo al progetto.
E' difficle spiegare in poche righe i problemi. Il codice è meno di 1000 righe ma sto andando in loop!

grazie a tutti!

[luxinterior]

Non voglio alimentare false speranze con ESP-IDF ci lavoro da un po ma ESP-NOW non l'ho mai affrontato
Se pensi che il problema sia legato a ESP-NOW sono già fuori
Altrimenti proviamo a vedere assieme io ho già utilizzato una libreria per fare aggiornamento del firmware "pescando" la verisone da un server remoto. Non ricordo particolari problemi (...ma la mia memoria fa cilecca sempre più spesso..)

[stefanopc]

"Chi lascia la strada vecchia per la nuova..."
Forse potresti rimanere col firmware che funziona senza problemi e attendere una nuova versione.
Io sto iniziando da poco e molto lentamente con qualcosa di simile per la gestione del fotovoltaico e il monitoraggio del solare termico tramite Home Assistant.
Ciao

[pusillus]

Grazie luxinterior!
In effetti il progetto è fortemente incentrato su ESP-NOW. Sul nodo ci sono due task che vanno in conflitto. il task che fa l'OTA update e quello che manda messaggi al gateway da inoltrare al server MQTT. il task dei messaggi parte all'avvio dell'applicazione ed ha una sua queue in attesa dei messaggi da inoltrare con ESPNOW, mentre il task OTA viene invocato da una richiesta del server. la cosa molto strana è che all'avvio se mando subito l'OTA upgrade tutto fila liscio. Se invece prima mando messaggi al server, l'OTA mi si pianta dopo che ha parzialmente scaricato un po di chunks. I due task apparentemente non utilizzano dati in comune, a parte ESP-NOW. Credo che ci sia qualche memory leak. Qualsiasi tentativo di migliorare la stuazione non fa altro che peggiorare le cose con vari "guru meditation errors". Se ti va di dargli comunque uno sguardo mi farebbe piacere. Magari prima sistemo il codice per renderlo più snello e leggibile ...con calma che devo trovare un po di tempo!

stefanopc
Sarà difficile "aspettare una nuova versione del firmware" perché l'ho scritto partendo da zero e quindi devo rilasciarmelo da me
Considera che per fare l'update OTA leggo circa 1000 alla volta bytes dal server http,i lo scompongo in pacchetti ESPNOW con il gateway e lo ricompongo sul nodo per poi scriverlo sulla flash. ESPNOW puo mandare solo 250bytes alla volta.

[luxinterior]

Non perderci tempo a sistemare il codice non serve
Nessun problema per guardare il tuo codicelo posso vedere prima però facciamo alcune cose
(Scusami in anticipo probabilmente ti metto dei consigli scontati...)

Metti nei punti strategici questa istruzione così controlli lo stato dell'allocazione memoria

Codice: Seleziona tutto

  ESP_LOGI (TAG, "MEM2 %u", heap_caps_get_free_size(MALLOC_CAP_SPIRAM)) ;

Io la metto in entrata e in unscita da un determinato codice per capire se ho lasciato memoria allocata in giro.
Se apri e chiudi un socket la memoria non viene liberata subito ma dopo un po di tempo Quindi metti un achiamata periodica da qualche parte.
Già così se vedi che la memoria cala di continuo vuol dire che ti rimangono pezzi allocati e devi indagare sul perché

Altra cosa quando attivi il task prova a ridurre di molto lo stack dedicato al task Se il problema appare subito o iil task nemmeno riesce a partire forse stai utilizzando male la ram interna. La ram interna su ESP32 è poca io mi sono abituato ad utilizzare il più possibile puntatori e malloc (o calloc) anche per variabili che normalmente sono statiche e non servirebbe allocazione dinamica, ma in questo modo utilizzi poca ram interna.

per l'ota non ho capito bene come fai l'operazione su internet ho trovato questo
nel cmakelists del progetto ho messo all'inizio queste righe

set(PROJECT_VER "1.0.1")
set(PROJECT_VERU ${PROJECT_VER})
set(PROJECT_PREF "esp32_4k")

string (REPLACE "\." "_" PROJECT_VERU ${PROJECT_VERU})
set(PROJECT_BIN "${PROJECT_PREF}_${PROJECT_VERU}")

Ti salva un binario col numero della versione che male non fa e inserisce la versione nel codice binario. In questo modo puoi da client interrogare il server e chiedere se c'è una nuova versione.
il client fa partire il download solo se le versioni sono diverse ed è il client che decide quando, così ti sincronizzi meglio con le tue attività.
In pratica scarico prima dal server un file json che mi dice qual è la versioen sul server e qual è il percorso per ottenerla e agisco di conseguenza
Una cosa del genere molto sintetico ma giusto per capire

Codice: Seleziona tutto


  const esp_partition_t *running = esp_ota_get_running_partition();
 
  esp_app_desc_t running_app_info;
  if (esp_ota_get_partition_description(running, &running_app_info) == ESP_OK)
  {
    ESP_LOGI(TAG, "Running firmware version: %s", running_app_info.version);
  }

  e poi qui confronta la versione attuale con la nuova
  if (memcmp(new_fw_version, running_app_info.version, strlen(new_fw_version)) == 0)



Altra trappola in cui spesso si cade (o meglio io cado) se hai coda di messaggi verifica che
La coda non saturi e che non ci sia più spazio per nuovi messaggi
I dati di un messaggio vengono sempre passati per copia quindi se passi buffer devi sempre liberarli quando elimini il messaggio. Se passi un puntatore libera la memoria del puntatore prima di liberare il messaggio.
E poi c'è il problerma inverso se ricevi un puntatore da un messaggio verifica sempre che i dati a cui punta siano consistenti Non tenere il puntatore e magari nel frattempo da un'altra parte quella memoria è stata rilasciata.

Ah dimenticavo hai modificato la partizione dlela memoria con le due aree ota tipo

Codice: Seleziona tutto

# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,      data, nvs,     0x009000,  0x6000,
otadata,  data, ota,     0x00F000,  0x2000,
phy_init, data, phy,     0x011000,  0x1000,
storage,  data, spiffs,  ,          900K
factory,  app,  factory, 0x100000,  2M,
ota_0,    app,  ota_0,   ,          2M,
ota_1,    app,  ota_1,   ,          2M,


e inserito il nome del file csv nell'sdkconfig

[pusillus]

luxinterior
Grazie dei consigli,
in effetti sarebbe il caso che controllassi meglio come viene utilizzata la memoria. Alcune accortezze che mi hai suggerito non le avevo considerate. Devo trovare un po di tempo per fare qualche verifica in più! Questi giorni non riesco, se ne parla la prossima settimana. Tra l'altro ho trovato questa discussione su github:

If a task will disable the cache (e.g., call an SPI flash write or NVS write operation), it would be a good idea to place that task entirely in internal RAM

https://github.com/espressif/esp-idf/issues/11216

Credo che dovrò fare in modo di far lavorare il task che scrive il Fimware sulla flash con la RAM interna e tutto il resto con la PSRAM.

Per la gestione degli update OTA, ancora devo occuparmi della gestione delle versioni, ma avevo gia pensato a qualcosa di simile a quello che hai usato tu.

[pusillus]

luxinterior
finalmente ho trovato un po di tempo per mettere le mani al firmware.
Sembra che funzioni adesso! Ho cercato di utilizzare il più possibile la SPIRAM perché il mio problema credo fosse un overflow sulla IRAM che nel ESP32-S2 è di 320 KB.
In particolare ho settato la SPIRAM :

Codice: Seleziona tutto

CONFIG_SPIRAM_USE_MALLOC=y

e spostato lo stack IP sulla SPIRAM:

Codice: Seleziona tutto

CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP=y

Il task che riceve il firmware dal gateway e lo scrive sulla flash l'ho fatto lavorare solo sulla IRAM.
mentre lavora ho questa memoria libera:

Codice: Seleziona tutto

W (162785) ota_store_task:  free iram: 89671
W (162785) ota_store_task:  free psram: 2031912

con qualche altra ottimizzazione potrei liberare altra IRAM.
grazie ancora dei consigli!

[luxinterior]

Ottimo!
Ma quindi adesso riesci a fare l'aggiornamento del firmware attraverso i messaggi da 250bytes di ESP NOW
Interessante...

[pusillus]

sembra di si. Ma devo fare prove più approfondite.
Se ti interessa condivido volentieri. Il codice è comunque da sistemare.

[luxinterior]

grazie Pusillus ti chiederò aiuto quando affronterò esp now.
Se hai tempo e voglia mi spieghi in due parole esp now io so solo che c'è non ho mai letto nulla