ESP32 OTA Updates

Basic Process for OTA Updates over Wifi

The general process is as follows:

• Some basic firmware needs to be uploaded to the ESP32 serially. This can be done fairly simply with a USB cable from a computer and a USB-UART bridge (i.e. with an FTDI chip). The firmware can be uploaded using a web server or with the Arduino IDE, see https://lastminuteengineers.com/esp32-ota-updates-arduino-ide/ for an in-depth tutorial, but it allows the ESP32 to connect to a WiFi network and poll in the background for OTA updates

  • Note that all firmware updates for the ESP32 must include this code, otherwise the OTA functionality will be lost

  • ESP32 micro will need an LNA I/O attached to an antenna for it to connect to a WiFi network

• Future updates can be sent out OTA, either through the Arudino IDE or using a web server. This will require knowing the IP address of the ESP32, which can be retrieved via serial output of the ESP32 during the first serial upload of the firwmare

Hardware Requirements:

• Must follow ESP32’s hardware design guidelines to set up the RF antenna in order to access WiFi (see https://www.espressif.com/sites/default/files/documentation/esp32_hardware_design_guidelines_en.pdf section 2.5)

• USB-UART bridge connecting to some kind of USB connector, in order for the first serial flashing of firmware to work. Also provides a backup method of flashing firmware and a debugging method. Some examples of how this can be wired up are provided below

  • https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf

  • https://dl.espressif.com/dl/schematics/ESP32-Demo-Board-V2_sch.pdf

ESP Backpack

The example Gemini module has an ESP-01F to act as a backpack. To implement this and connect it to WiFi, a guide is available (https://www.instructables.com/Getting-Started-With-the-ESP8266-ESP-01/). The schematic design will likely be the similar, if not exactly the same as the example module.

A backpack is essentially a wireless device that acts as a middle-man between the ERLS device and another wireless device to easily reconfigure frequency and wireless channels.

• Not sure how it’s meant to be used in the example Gemini module, as according to ERLS website (https://www.expresslrs.org/hardware/backpack/esp-backpack/#what-is-a-backpack) the backpack is wired to the wireless device and connects wirelessly to the ERLS transmitter, but in the example Gemini module it is wired directly to the ESP32 that talks to the RF transmitters. The ESP32 could just be reconfigured directly if it can be updated OTA

UPDATE: So the backpack isn’t for the Gemini module, it’s just the ground-side portion of the backpack.

For a backpack to work, there needs to be a backpack on the ground-side (i.e. the TX controller) and a backpack on the drone (basically any similar micro w/ an antenna). The backpack on the Gemini side is the thing that contacts the backpack on the drone to send the new frequency & channel info to update the drone-side devices. It doesn’t update anything on the Gemini module itself. As such, it’s really an optional tool to include. Instead of being flashed over WiFi or USB like the ESP32, the ESP32 passes along the firmware via UART.

• Based on all this, I think it wouldn’t hurt to include the ESP-01F backpack. It would probably be best to have a backup method of flashing it (i.e. serial connection, WiFi won’t work as it’s antenna is reserved for contacting the drone’s backpack)

Conclusion

• Proceed with any ESP32 micro as long as it has a LNA I/O and SPI capabilities (to talk with the SX1280 RF IC) (the ESP32-PICO4 in the example Gemini can be used)

• Reuse the Micro-USB connection shown in the example ESP32 module schematics above, but be sure to understand how it works

  • A certain procedure for toggling the BOOT0 and reset pins must be followed in order to allow the ESP32 to begin looking for OTA updates, as explained in the tutorial, so it’s important to understand how this is done and how it’s implemented/if it should be implemented differently to be easier

• Note that we probably can’t connect the ESP32 to eduroam as it requires additional sign in information (UWaterloo credentials), but any WiFi hotspot from a computer or smartphone should work

  • This will probably be how it will be used at comp., as there probably won’t be an open WiFi network to use and so a mobile data hotspot could be used instead. That is of course only if we suddenly need firmware updates to the controller (i.e. to reconfigure the transmitters to change frequencies/channels)

STM32 OTA Updates

Useful Resources:

: Detailed guide on antennas & antenna selection, some stuff on BLE as well which can be relevant, can be useful if designing custom bluetooth.

In general, I’d recommend against an entirely custom Bluetooth solution, as the protocols for properly broadcasting in Bluetooth is a steep learning curve and probably not suitable for this project.

: Guide on how to write a custom bootloader for an STM32 chip. The tutorial eventually progresses into making the bootloader work with OTA (over the air) firmware updates with a Bluetooth module, however the solution they provide is very slow and unoptimized, so it probably wouldn’t be suitable for our purposes.

https://www.st.com/resource/en/application_note/an5247-overtheair-application-and-wireless-firmware-update-for-stm32wb-series-microcontrollers-stmicroelectronics.pdf : STM32 App note explaining how to do OTA firmware updates with STM32WB MCUs.

• Using this series of MCUs probably isn’t possible for us as they all have pretty tight QFN or BGA footprints, which will be hard to assemble in house without issues. However, it may be possible to use the same software & principles from that app note with other STM32 MCUs

: Explanation of how to use UART to work with the STM32 bootloader. By following the steps in this video and using STM’s FLASHER-STM32 software, we can transmit a .bin firmware package from a computer to an STM32 over UART. This can be extended to be over Bluetooth for OTA firmware updates

Modules for Consideration:

453-00005 Laird Connectivity Module or RN4871U-V/RM118: Solid ICs, require some firmware development for setup and connection. Would be fairly complex to implement, due to amount of work and development needed to support it.

• RN4871 comes with a guide on how to communicate w/ it (https://ww1.microchip.com/downloads/en/DeviceDoc/50002466B.pdf), still fairly complicated but it supports multiple different protocols, could be good as a challenge

RN4020-V/RMBEC133: Moderate complexity, comes with a guide on how to communicate w/ IC and broadcast (http://ww1.microchip.com/downloads/en/devicedoc/70005191b.pdf). Seems fairly straightforward and not too complicated to implement both HW and firmware, a good fit if we’re interested in something a bit more challenging.

Arduino Nano 33 BLE: COTS solution, can be integrated onto a PCB with headers, can also be used w/ Arduino’s library for quicker & easier FW development. Probably on the easier/more reliable side of things, but power consumption isn’t known (though it shouldn’t be too high based on modules of similar form factor).

COTS Bluetooth 4.0 BLE Module: An example is linked, but there are plenty of possible choices. Connection is straightforward, requires a mobile app (either a Bluetooth finder from an app store or a simple custom made one) to connect to it and transmit information.

Conclusion

Further research is needed. As a preliminary decision, the best way to probably go about this is:

• PC uses FLASHER-STM32 to send firmware over USB via UART

• An FTDI chip or cable breaks this out to UART signals

• UART signals go to a Bluetooth module (e.g. the Arduino BLE) which is programmed to connect to a Bluetooth receiver on the Gemini PCB and transmit all incoming UART over Bluetooth to the receiver

• To get the OTA update, the pilot will manually put the STM32 on the Gemini PCB into the bootloader (via buttons that toggle the BOOT pins), allowing the STM32 to receive the OTA update via UART from the Bluetooth receiver