Hur man utför OTA-uppdateringar (Over-the-Air) med ESP32-microcontrollern och dess ESP-IDF

Av Jacob Beningo

Bidraget med av DigiKeys nordamerikanska redaktörer

Konstruktörer av IoT-produkter (Internet of Things) måste hela tiden utvärdera val av plattformar och komponenter för att minska kostnader och strömförbrukning, samtidigt som de förbättrar prestandan och påskyndar utformningen av konnektivitetsmöjligheterna. Det finns för närvarande ett antal lösningar att välja mellan, men konstruktörerna står inför en utmaning när det gäller trådlösa OTA-uppdateringar (over-the-air) för att hålla enhetens firmware uppdaterad när den väl är installerad.

Nyckeln är att titta på tillgängliga plattformar för att se vilka verktyg och vilket stöd de har för att stödja OTA-uppdateringar. Stöd kan för detta förenklar processen avsevärt, men det kan kräva att det tas hänsyn till redan från början.

I denna artikel diskuteras grunderna om OTA och varför det är en kritisk funktion som nästan alla IoT-system måste stödja, trots de utmaningar som utvecklarna står inför. Därefter används Espressif Systems ESP32 Bluetooth- och Wi-Fi-aktiverade microcontroller med tillhörande moduler, satser och ESP IoT Development Framework (ESP-IDF) för att visa hur man skapar en OTA-partition och använder skriptet otatool.py för att utföra en uppdatering av den fasta programvaran medan ett program fortfarande körs.

Introduktion till OTA-uppdateringar

De flesta utvecklingsteam fokuserar på att implementera sina produktspecifika funktioner, alltså den affärslogik som gör produkterna differentierade. Alla IoT-produkter har dock en basfunktionalitet som måste installeras, konfigureras och underhållas under enhetens hela livstid. Säkerhetsuppdateringar är ett bra exempel. Med tanke på behovet av att utföra dessa uppdateringar, är en viktig, men lätt förbisedd, funktion när man utvärderar utvecklingsplattformar, bootloadern eller möjligheten till OTA-uppdatering av firmware (FOTA) (ibland bara kallad OTA).

OTA ger ingenjörer möjlighet att på distans underhålla och uppgradera sina produkter för att uppfylla både tekniska och affärsmässiga krav utan att behöva skicka ut underhållspersonal till enheten eller få slutkunden att aktivt göra något med enheten för att uppdatera den. Istället kan alla dessa kostnader elimineras genom att enheterna tyst uppgraderar sin firmware i bakgrunden eller under driftpauser, exempelvis mitt i natten.

OTA-arkitekturer kan finnas i många olika former och konfigurationer, från specialbyggda lösningar till standardimplementationer som tillhandahålls av molnleverantörer. Ett typiskt exempel på arkitektur kan ses i figur 1.

Diagram över OTA-arkitekturen som visar ett exempel på en process för uppdatering av fast programvara (firmware)Figur 1: En översikt över arkitekturen för OTA, som visar en exempelprocess för uppdatering av fast programvara i fält till utplacerade enheter. (Bildkälla: Beningo Embedded Group)

I det här exemplet använder en OEM-leverantör Amazon Web Services IoT-kärna för att ladda upp nya versioner av den fasta programvaran och använder sedan de inbyggda Job-funktionerna för att distribuera uppdateringar till enheter på fältet. Detta är bara ett av många exempel och nästan alla molnleverantörer har en liknande lösning.

Det finns många microcontroller som stöder OTA. En populär microcontroller för både billiga system och bland tillverkare är ESP32. Det finns flera anledningar till varför ESP32 har varit så populär, bland annat:

  • Den har en integrerad microcontroller med tillgängliga Wi-Fi-/Bluetooth-certifieringsmoduler
  • Låg kostnad
  • Utvecklingsmiljö och programvaruramar med öppen källkod, t.ex. ESP-IDF och ESP Audio Development Framework (ESP-ADF)
  • Många befintliga tillämpningsexempel finns fritt tillgängliga på webben

Välja en ESP32-modul för OTA-testning

Det finns flera olika ESP32-moduler och utvecklingskort som användare kan köpa för att gå igenom OTA-exemplen. Låt oss exempelvis titta på Adafruits 3405 ESP32 Huzzah Feather-kort 3405 ESP32 (figur 2). Detta är ett billigt utvecklingskort som innehåller alla kretsar för att programmera en ESP32 och driva den via en USB-kontakt.

Bild av Adafruit 3405 Huzzah Feather-kortFigur 2: 3405 Huzzah Feather-kortet innehåller en ESP32 WROOM-32D-certifierad Wi-Fi-/Bluetooth-modul med 4 Mbyte Flash. Kortet innehåller all hårdvara som behövs för att programmera och kommunicera med modulen via USB. (Bildkälla: Adafruit)

Kärnan i 3405 är en ESP32-WROOM-32D-modul som levereras med 4 Mbyte flash, Wi-Fi, Bluetooth och en komplett uppsättning kringkretsar för nästan alla tänkbara tillämpningar.

Ett annat utvecklingskort som kan användas är Espressif Systems ljudkort ESP32-LYRATD-SYNA (figur 3). Detta utvecklingskort innehåller ESP32-WROVER-B-modulen.

Bild av Espressif Systems ESP32-LYRATD-SYNA BoardFigur 3: ESP32-LYRATD-SYNA-kortet är baserat på en ESP32 WROVER-B-certifierad Wi-Fi-/Bluetooth-modul med 4 Mbyte flash. Förutom att konstruktörer kan programmera och kommunicera med modulen via USB har den också de kretsar som behövs för att utveckla ljudtillämpningar. (Bildkälla: Espressif Systems)

ESP32-LYRATD-SYNA-modulen har också 4 Mbyte Flash och alla kretsar för ljudtillämpningar. Kortet innehåller en ljudcodec, en ljudförstärkare samt hörlurs- och högtalaruttag för att testa en ljudtillämpning fullt ut.

Ett sista utvecklingskort som kan användas för OTA-testning är Espressifs utvecklingskort ESP32-S2-SAOLA-1RI- (figur 4). När det gäller utvecklingskort är detta det billigaste. Kortet innehåller en ESP32 Wrover-modul tillsammans med kretsarna som behövs för att programmera chipet. Det finns inget bjäfs, förutom att den har stift som gör att den enkelt kan sättas ner i ett kopplingsdäck för testning.

Bild av Espressif Systems ESP32-S2-SAOLA-1RI som är baserat på Wrover-modulenFigur 4: ESP32-S2-SAOLA-1RI, som bygger på Wrover-modulen, är ett billigt utvecklingskort som innehåller nödvändiga kretsarna för att programmera den inbyggda modulen. (Bildkälla: Espressif Systems)

Det specifika kortet som valts för testning spelar ingen större roll eftersom varje ESP32-modul utnyttjar ESP-IDF. Detta ramverk är utformat för att underlätta programvaruutvecklingen för utvecklare genom att inkludera drivrutiner, mellanprogramvara, ett RTOS och - viktigt i denna artikels sammanhang - bootloaders och OTA-bibliotek.

Bootloadern gör det möjligt för utvecklare att utnyttja OTA-uppdateringar och partitionera minnet för att uppdatera den fasta progamvaran medan den primära applikationen fortfarande körs, vilket bidrar till att minimera stilleståndstiden. Konfigureringen av bootloadern kan verka komplicerad till en början, men den är okomplicerad med lite hjälp på vägen.

Arbetsflödet för OTA-utveckling

Arbetsflödet för OTA-utveckling för ESP32 kommer att variera något beroende på verksamhetens behov och valet av produktkomponenter. Ett team som använder AWS kommer t.ex. troligen att använda AWS startguider och exempel för att få sin ESP32 OTA-lösning att fungera. Ett företag som utvecklar en egen lösning kommer däremot troligen att använda ESP32-dokumentationen. I denna artikel tittar vi på beståndsdelarna på ESP32-nivå och inte i molnet. Anledningen är att dessa delar är generiska och gäller för OTA med ESP32, oavsett vilken molnleverantör eller lösning som används.

Generellt sett innebär processen för att ställa in en OTA-uppdatering på ESP32 följande steg:

  1. Konfigurera ESP32-partitionstabellen
  2. Ladda ner firmware som stöder OTA
  3. Utveckla ett verktyg som fungerar som en server och skicka ut ny firmware
  4. Ladda ner den senaste fasta programvaran till ESP32
  5. Byt till det nya programmet

Detta är naturligtvis den förenklade metoden. Utvecklare bör titta på figur 1 igen för att få en bild av den övergripande processen för uppdatering av fast programvara. Denna process kan vara ganska komplicerad, så det rekommenderas att använda de befintliga ESP32 OTA-exemplen på GitHub. Dessa exempel ger flera kritiska exempel, t.ex:

  • HTTPS OTA
  • Egen OTA
  • Enkel OTA
  • OTA-verktyg (exempel på python-skript)

I figur 5 visas stegen i installations- och uppdateringsprocessen. En utvecklare måste först utföra stegen i rött för att distribuera OTA-lösningen till ESP32-modulen. De orangefärgade stegen är nästa steg och utförs för att underlätta en OTA-uppdatering.

Diagram över Espressif Systems OTA-uppdateringsexempelFigur 5: Espressif Systems OTA-uppdateringsexempel på GitHub ger utvecklare flera enkla exempel på hur de kan få sin ESP32 att utföra OTA-uppdateringar. (Bildkälla: Espressif Systems)

Konfigurera en ESP32-applikation för OTA

ESP32 innehåller en partitionstabell som beskriver vilken typ av data som finns på microcontrollern och var den finns. En standardpartitionstabell för ESP32 ser till exempel ut som Tabell 1:

Bild på standardpartitionstabell för ESP32Tabell 1: En ESP32-standardpartitionstabell som visar vilken typ av data som finns och var den är placerad på microcontrollern. (Tabellkälla: Beningo Embedded)

Vi har den fabriksinstallerade applikationen och sedan en sektion för NVS-biblioteket och initialiseringsdata (init) för det fysiska lagret (PHY). För att kunna använda OTA-funktionen måste denna tabell uppdateras så att det finns minnesplatser som är specificerade för den fasta programvaran för OTA-uppdateringar, utöver den primära (fabriks-)applikationen. För OTA finns det vanligtvis två partitioner som är tilldelade för uppdateringar. En för den aktiva uppdaterade fasta programvaran och en för den fasta programvaran som håller på att laddas ner och som kommer att bli den senaste versionen. Detta gör att fabriksapplikationen kan förbli intakt. En uppdaterad OTA-partitionstabell skulle se ut ungefär som tabell 2.

Bild av typisk OTA-uppdaterad ESP32-partitionstabellTabell 2: typisk OTA-uppdaterad ESP32-partitionstabell. (Tabellkälla: Beningo Embedded)

Som synes finns det nu en ota_0- och en ota_1-applikationssektion som är 1 Mbyte stor, förutom en datasektion (otadata) som är RAM-allokerad för uppdateringsprocessen. Denna tabell kan ändras och uppdateras av utvecklaren till att passa applikationen.

För att köra OTA-exemplet finns det en enkel uppsättning instruktioner som listas på GitHub under avsnittet "How to use the examples". Här beskrivs hur du bygger och programmerar programmet.

Det finns också verktyget otatool som kan användas för att uppdatera firmware. Detta skript används vanligtvis för att:

  • Läsa, skriva och radera OTA-partitioner
  • Växla startpartitioner
  • Växla till fabrikspartition

Exempelskriptet kan exekveras genom att helt enkelt köra exemplet i en terminal med kommandot:

./otatool_example.sh

Eller använda Python:

python otatool_example.py

När det gäller att konfigurera ESP32 för OTA är det viktigt att se till att partitionerna är konfigurerade.

Tips och tricks för användning

EPS32-OTA-lösningen kan göra det snabbare och enklare för utvecklare att hitta en lösning för att uppdatera den fasta programvaran. För att undvika att lösningen blir en utvecklingsbörda finns det flera tips och tricks som man kan lägga på minnet:

  • Använd om möjligt ett befintligt OTA-ramverk som ingår i företagets molnleverantör. Detta kan dramatiskt förenkla utvecklingen och integrationen.
  • Använd ett billigt utvecklingskort för att testa OTA-funktioner och -bootloaders. ESP32 har flera möjligheter och det kan krävas lite experimenterande för att avgöra vilka som är bäst för det aktuella programmet.
  • För egna lösningar kan du använda ESP32 OTA-exemplen på GitHub.
  • För tillämpningar där produkten fungerar som Wi-Fi-router eller hub, kan du överväga att ladda ner en avbildning av den inbyggda programvaran till ett externt minne och göra en uppdatering från en masslagringsenhet.
  • Lägg lite tid på att läsa igenom ESP32-dokumentationen om partitionstabeller. Detta skiljer sig lite från den typiska microcontrollerimplementeringen.
  • Av säkerhetsskäl är det bäst att inaktivera återställning av program. Om programmet kan återgå till tidigare versioner kan angriparna potentiellt forcera igenom en version med en känd säkerhetsbrist och äventyra systemet.

Utvecklare som följer dessa "tips och tricks" kommer att upptäcka att de sparar en hel del tid och problem när de försöker utnyttja ESP32 eller någon annan OTA-lösning.

Slutsats

OTA-uppdateringar är en viktig funktion för allt fler IoT- och inbyggda system. Utvecklare måste få ett bra grepp om hur man gör detta effektivt för att spara tid i början av konstruktions- och utvecklingsprocessen och efter att produkten har levererats.

Den trådlösa microcontrollern ESP32 finns numer i ett stort antal enheter, och som vi visat har den en komplett och färdig OTA-lösning. Genom att dra nytta av ESP-IDF och tillhörande moduler och plattformar, och genom att använda några erfarenhetsbaserade tips och tricks, kan utvecklare dramatiskt förkorta konstruktionstiden och få igång sin egen OTA-lösning.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

Om skribenten

Image of Jacob Beningo

Jacob Beningo

Jacob Beningo är konsult inom inbäddad programvara. Han har publicerat över 200 artiklar om utveckling av inbäddad programvara, och är en eftertraktad talare och teknisk utbildare med tre examina, däribland en master i teknik från University of Michigan.

Om utgivaren

DigiKeys nordamerikanska redaktörer