[Answered] Any recipes for over the air flashing/program loading?

[kolban]

My current experimentation workflow is:

• Edit
• Compile
• Flash
• Run
• ... repeat

While this works great, the "Flash" step takes time. While more than acceptable, I believe I have the opportunity to flash new code into an ESP32 through WiFi (i.e. Over The Air - OTA). Is this area functional at this time? Do we have a recipe to achieve such?

[ESP_Sprite]

Can't help you with ota at the moment - still need to get some experience with that. For flashing, it may pay off to select a higher baud rate and/or compression - should make flashing less painful.

[kolban]

Thank you as always sir. Your posts are gold. I wasn't sure what you meant by compression so did some digging. I'm not 100% sure I got it all but here is the story in case others may find it useful.

When we extract the ESP-IDF template for a project, we can run "make menuconfig" which opens up a menu for configuration of our project's environment. From the main menu page there is an option called "Serial flasher config --->". If we select that, there is an option that we can enable called "Use compressed upload".



Once selected, it changes the configuration file for the project (sdkconfig). Next build will rebuild the ESP-IDF. Now when we flash by running "make flash", we see some new output (that was not seen when the compression options was not selected):



what this seems to show is that the size of data transmitted over serial has reduced from 362K to 202K (a reduction of over 40%!!).

Very Very nice!!!

[ESP_Sprite]

Do also try to change the default baud rate. It only affects the serial flasher baud rate, not the runtime rate, and 99% of the boards will be able to do at least 230400 baud, which is twice as fast as what you have now. If you can get the baud rate up to 921600, you can reflash a sizable project in about 5 seconds.

[kolban]

I tried 230400 baud and as you suggested, it seemed to work. I did notice a new quirk which is probably how I am working or using the device. Realize that I might be making horrible mistakes here ...

I have an application running which is effectively a serial console. This is running on my Raspberry Pi running Linux. The Pi is then connected to the DevKitC through USB/Serial. This allows me to monitor the console of the ESP32. When I wish to flash, I toggle the EN and GPIO0 pins appropriately and then run "make flash" from within an app project directory. What I don't do is disconnect the serial terminal. This gives me a workflow of edit->compile->flash->run ... repeat ... in one window while a second window maintains a console output of the ESP32. All good.

When I flash with a baud rate of 115200, after the flash and I reboot the ESP32 ... the ESP32 log messages start appearing immediately ... because my terminal is set to show at 115200. When I tried flashing at 230400, it seemed that I was able to flash at the correct speed ... I am assuming that somehow the ESP32 "detected" the baud rate ... however on reboot, the initial console messages that appeared were "gibberish" ... my guess is that the ESP32 rebooted and maintained the 230400 output while my serial terminal was expecting 115200 on the Pi. What I then find is that shortly after boot, the ESP32 switches back to outputing at 115200 so it isn't a case of simply switching my terminal to a speed of 230400. I suspect that there may be some setting somewhere which tells the ESP32 what baud rate to use for serial output ... but I haven't come to it yet.

[ESP_Sprite]

I am actually somewhat surprised esptool.py doesn't fail outright with the serial terminal started. The normal way of doing things is either having the terminal up, or flashing the ESP; not both.