say you have a thousand iot devices out in the field. now, if one fine day, you find a bug in the production code, and wish to fix it, will you recall all the thousand devices and flash the new firmware in them? probably not! what you'll prefer to have is a way to update all the devices remotely, over-the-air. ota updates are very common these days. every now and then, you keep receiving software updates to your android or ios smartphones. just like software updates can happen remotely, so can firmware updates. in this chapter, we will look at how to update the firmware of esp32 remotely.

ota update process

the process is quite simple. the device first downloads the new firmware in chunks and stores it in a separate area of the memory. let's call this area the 'ota space'. let's call the area of the memory where the current code or the application code is stored as the 'application space'. once the entire firmware has been downloaded and verified, the device bootloader swings into action. consider the bootloader as a code written in a separate area of the memory (let's call it the 'bootloader space'), whose sole purpose is to load the correct code in the application space every time the device restarts.

thus, every time the device restarts, the code in the bootloader space gets executed first. most of the time, it simply passes control to the code in the application space. however, after downloading the newer firmware, when the device restarts, the bootloader will notice that a newer application code is available. so it will flash that newer code from the ota space into the application space and then give control to the code in the application space. the result will be that the device firmware will be upgraded.

now, digressing a bit, the bootloader can also flash the factory reset code from the 'factory reset space' to the application space, if the application code is corrupted, or a factory reset command is sent. also, often, the ota code and the factory reset codes are stored on external storage devices like an sd card or an external eeprom or flash chip, if the microcontroller doesn't have enough space. however, in the case of esp32, the ota code can be stored in the microcontroller's memory itself.

code walkthrough

we will be using an example code for this chapter. you can find it in file −> examples −> update −> aws_s3_ota_update. it can also be found on github.

this is one of the very detailed examples available for esp32 on arduino. the author of this sketch has even provided the expected serial monitor output of the sketch in comments. so while much of the code will be self−explanatory through the comments, we'll walk over the broad idea and also cover the important details. this code makes use of the update library which, like many other libraries, makes working with esp32 very easy, while keeping the rigorous work under−the−hood.

in this specific example, the author has kept the binary file of the new firmware in an aws s3 bucket. providing a detailed overview of aws s3 is beyond the scope of this chapter, but very broadly, s3 (simple storage service) is a cloud storage service provided by amazon web services (aws). think of it like google drive. you upload files to your drive and share a link with people to share it. similarly, you can upload a file to s3 and access it via a link. s3 is much more popular because a lot of other aws services can interface seamlessly with it. getting started with aws s3 will be easy. you can get help from several resources available through a quick google search. in the comments at the beginning of the sketch as well, a few steps to get started are mentioned.

an important recommendation to note is that you should use your own binary file for this code. the comments at the top of the sketch suggest that you can use the same binary file that the author has used. however, downloading a binary compiled on another machine/ another version of arduino ide has been known to cause errors sometimes in the ota process. also, using your own binary will make your learning more 'complete'. you can export the binary of any esp32 sketch by going to sketch −> export compiled binary. the binary (.bin) file gets saved in the same folder in which your arduino (.ino) file is saved.

once your binary is saved, you just need to upload it to s3 and add the link to the bucket and address of the binary file in your code. the binary you save should have some print statement to indicate that it is different from the code you flash in the esp32. a statement like "hello from s3" maybe. also, don't keep the s3 bucket link and bin address in the code as it is.

alright! enough talk! let's begin the walkthrough now. we will begin by including the wifi and update libraries.

#include <wifi.h>
#include <update.h>

next, we define a few variables, constants, and also the wificlient object. remember to add your own wifi credentials and s3 credentials.

wificlient client;

// variables to validate
// response from s3
long contentlength = 0;
bool isvalidcontenttype = false;

// your ssid and pswd that the chip needs
// to connect to
const char* ssid = "your−ssid";
const char* pswd = "your−ssid−pswd";

// s3 bucket config
string host = "bucket−name.s3.ap−south−1.amazonaws.com"; // host => bucket−name.s3.region.amazonaws.com
int port = 80; // non https. for https 443. as of today, https doesn't work.
string bin = "/sketch−name.ino.bin"; // bin file name with a slash in front.

next, a helper function getheadervalue() has been defined, which basically is used to check the value of a particular header. for example, if we get the header "content-length: 40" and it is stored in a string called headers, getheadervalue(headers,"content−length: ") will return 40.

// utility to extract header value from headers
string getheadervalue(string header, string headername) {
   return header.substring(strlen(headername.c_str()));
}

next, the main function execota(), which performs the ota. this function has the entire logic related to the ota. if you look at the setup, we simply connect to the wifi and call the execota() function.

void setup() {
   //begin serial
   serial.begin(115200);
   delay(10);

   serial.println("connecting to " + string(ssid));

   // connect to provided ssid and pswd
   wifi.begin(ssid, pswd);

   // wait for connection to establish
   while (wifi.status() != wl_connected) {
      serial.print("."); // keep the serial monitor lit!
      delay(500);
   }

   // connection succeed
   serial.println("");
   serial.println("connected to " + string(ssid));

   // execute ota update
   execota();
}

so you would have understood that understanding the execota function means understanding this entire code. therefore, let's begin the walkthrough of that function.

we begin by connecting to our host, which is the s3 bucket in this case. once connected, we fetch the bin file from the bucket, using a get request (refer to the http tutorial for more information on get requests)

void execota() {
   serial.println("connecting to: " + string(host));
   // connect to s3
   if (client.connect(host.c_str(), port)) {
   // connection succeed.
   // fecthing the bin
   serial.println("fetching bin: " + string(bin));

   // get the contents of the bin file
   client.print(string("get ") + bin + " http/1.1\r\n" +
      "host: " + host + "\r\n" +
      "cache-control: no-cache\r\n" +
      "connection: close\r\n\r\n");

next, we wait for the client to get connected. we give a maximum of 5 seconds for the connection to get established, otherwise we say that the connection has timed out and return.

unsigned long timeout = millis();
while (client.available() == 0) {
   if (millis() - timeout > 5000) {
      serial.println("client timeout !");
      client.stop();
      return;
   }
}

assuming that the code has not returned in the previous step, we have a successful connection established. the expected response from the server is provided in the comments. we begin by parsing that response. the response is read line by line, and each new line is stored in a variable called line. we specifically check for the following 3 things −

if the response status code is 200 (ok)
what is the content-length
whether the content type is application/octet-stream (this is the type expected for a binary file)

the first and third are required, and the second is just for information.

while (client.available()) {
   // read line till /n
   string line = client.readstringuntil('\n');
   // remove space, to check if the line is end of headers
   line.trim();

   // if the the line is empty,
   // this is end of headers
   // break the while and feed the
   // remaining `client` to the
   // update.writestream();
   if (!line.length()) {
   //headers ended
   break; // and get the ota started
   }

   // check if the http response is 200
   // else break and exit update
   if (line.startswith("http/1.1")) {
      if (line.indexof("200") < 0) {
         serial.println("got a non 200 status code from server. exiting ota update.");
         break;
      }
   }

   // extract headers here
   // start with content length
   if (line.startswith("content-length: ")) {
      contentlength = atol((getheadervalue(line, "content-length: ")).c_str());
      serial.println("got " + string(contentlength) + " bytes from server");
   }

   // next, the content type
   if (line.startswith("content-type: ")) {
      string contenttype = getheadervalue(line, "content-type: ");
      serial.println("got " + contenttype + " payload.");
      if (contenttype == "application/octet-stream") {
         isvalidcontenttype = true;
      }
   }
}

with this, the if block that checks if the connection with the server was successful ends. it is followed by the else block, which just prints that we were unable to establish connection to the server.

} else {
   // connect to s3 failed
   // may be try?
   // probably a choppy network?
   serial.println("connection to " + string(host) + " failed. please check your setup");
   // retry??
   // execota();
}

next, if we have hopefully received the correct response from the server, we will have a positive contentlength (remember, we had initialized it with 0 at the top and so it will still be 0 if we somehow did not reach that line where we parse the content−length header). also, we will have isvalidcontenttype as true (remember, we had initialized it with false). so we check if both of these conditions are true and if yes, proceed with the actual ota. note that so far, we have only made use of the wifi library, for interacting with the server. now if the server interaction turns out to be alright, we will begin use of the update library, otherwise, we simply print that there was no content in the server response and flush the client. if the response was indeed correct, we first check if there is enough space in the memory to store the ota file. by default, about 1.2 mb of space is reserved for the ota file. so if the contentlength exceeds that, update.begin() will return false. this 1.2mb number can change depending on the partitions of your esp32.

// check contentlength and content type
if (contentlength && isvalidcontenttype) {
   // check if there is enough to ota update
   bool canbegin = update.begin(contentlength);

now, if we indeed have space to store the ota file in memory, we begin writing the bytes to the memory area reserved for ota (the ota space), using the update.writestream() function. if we don't, we simply print that message and flush the client, and exit the ota process. the update.writestream() function returns the number of bytes that were written to the ota space. we then check if the number of bytes written is equal to the contentlength. if the update is completed, in which case the update.end() function will return true, we check if it has finished properly, i.e. all bytes are written, using the update.isfinished() function. if it returns true, meaning that all bytes have been written, we restart the esp32, so that the bootloader can flash the new code from the ota space to the application space, and our firmware gets upgraded. if it returns false, we print the error received.

   // if yes, begin
   if (canbegin) {
      serial.println("begin ota. this may take 2 − 5 mins to complete. things might be quite for a while.. patience!");
      // no activity would appear on the serial monitor
      // so be patient. this may take 2 - 5mins to complete
      size_t written = update.writestream(client);

      if (written == contentlength) {
         serial.println("written : " + string(written) + " successfully");
      } else {
         serial.println("written only : " + string(written) + "/" + string(contentlength) + ". retry?" );
         // retry??
         // execota();
      }

      if (update.end()) {
         serial.println("ota done!");
         if (update.isfinished()) {
            serial.println("update successfully completed. rebooting.");
            esp.restart();
         } else {
            serial.println("update not finished? something went wrong!");
         }
      } else {
         serial.println("error occurred. error #: " + string(update.geterror()));
      }
   } else {
      // not enough space to begin ota
      // understand the partitions and
      // space availability
      serial.println("not enough space to begin ota");
      client.flush();
   }
}

of course, you would have realized by now that we need not do anything in the loop here.

that's it. you've successfully upgraded the firmware of your esp32 chip remotely. if you are more curious about what each function of the update library does, you can refer to the comments in the update.h file.

references

ota on esp32

Save or share this article