ESP32 Forum

Hello everyone,
I'm in need of some clarification and suggestions about a future project.
This project involves an ESP32 powered board connected via a 485 serial cable to a master. It should be possible for both devices' firmware to be upgradable, so I would be killing two birds with one stone if I was able to connect to the master and then flash the ESP32 board through the UART connection.

Now, the perfect solution would be to simply use the default flashing UART port for both programming and communicating. This however poses two problems:
1. The bootloader serial protocol looks cumbersome to implement. It should be implemented in a similar MCU-powered board from scratch.
2. I should add two signals to the serial cable to manage IO0 and reset.

Additionally I would like to avoid flashing the whole binary every time (libraries, FreeRTOS and such). The firmware itself should be pretty simple.

Assuming my understanding up until now is correct, what I would need is to receive the firmware update as part of the normal communication protocol, store it somewhere (possibly NVS flash), check it and then overwrite my own flash.
In many ways it's similar to this question https://www.esp32.com/viewtopic.php?t=2655 which has an answer from Kolban himself. Starting from that I studied a bit and at this point I'm not sure how I should proceed. Can I split my binary firmware into "framework" and "app"? The esp-idf makefile environment has an "app-flash" option, is it what I need?
I guess the official solution to this is the whole OTA section of the esp-idf, but here I am not using either WiFi or Bluetooth, just plain UART.

maldus:

My first suggestion is to study much more on the topic. Your questions suggests you do not know enough to do this yourself and are looking for a solution already designed - which I can tell you is not to be found.

As I understand, you have a board which contains an ESP32. It is connected to another device via an rs485 cable and you want to be able to update your code via uart communication.

This can be easily done, but it takes you understanding the complete process where you can write the code and debug it without expecting any outside help (just being blunt as I have found little help when using the ESP outside the box).

#1. Study on partitions. You should use two or more code partitions as if you were doing OTA.

#2. Study the code that is supplied in the IDF that actually performs an OTA update (say over http) - then you will learn the "low level" functions to use in your own code - WITHOUT using wifi or BT.

#3. You have to define your own uart protocol to put your ESP into code acquisition mode. That code should include handshaking and crc checks to make sure the code is acquired without error. Then, for each received uart packet, write the code into the OTA partition for the update.

#4. Once your new code is in the new OTA partition, you update the boot partition to boot to your new code and perform a reset.

#5. Your code will consist of the entire IDF+Your code compilation. You can not separate out component blocks.

Once you have studied and really understand all of the ESP IDF "low level" functions required to perform your task, you should be able to write this in one day.

The best part of this type of project is all the stuff you will learn about the ESP and that you don't need to depend on the ESP team or the IDF to accomplish your task.

I'm sorry if I come across cold or harsh. I read so many times users expect to find solutions already designed. Your's is a simple problem but it takes time to learn what is required to implement it.

Hope that helps.

#2. Study the code that is supplied in the IDF that actually performs an OTA update (say over http) - then you will learn the "low level" functions to use in your own code - WITHOUT using wifi or BT.

This was the answer I was looking for. Everything else - serial protocol, checksum, additional partition - was a given for me, but I wasn't sure whether there was something more appropriate (like the low level SPI API).

#5. Your code will consist of the entire IDF+Your code compilation. You can not separate out component blocks.

That was the most confusing part, because Kolban's answer on the linked question seemed to suggest this, that I can simply flash a single function at a specific memory address and then execute it by branching to said address.

All things considered, if I really want to flash only a small part of the firmware I guess the best way would be to run an interpreter like microPython or Lua-RTOS. Performance isn't important in my project, and if they were reliable enough I could simply receive a script file over UART and save it on the local filesystem.

I'll study some code then. Thank you for the suggestion!

The link regarding Kolban's response was about implementing a "custom Bootloader".

To get an idea of where it started -- do a google search for "RBOOT" - or use the link below.

https://richard.burtons.org/2015/05/

The ESP8266 had a fixed bootloader and no way of implementing an easy OTA.

If I'm not mistaken, it was Richard's work that Kolban is referring to and also what motivated Espressif to offer multi-boot capabilities.

The ESP32 partitions for OTA really implements the "intent" of Richard's work.