Firmware OTA Updates: At the beginning

Published on TodayInternet des Objets Connectés
Firmware OTA Updates: At the beginning

Dear fans of electronics, embedded systems. We present here our beginnings on a subject born from the consequences of various problems encountered during the realization of our projects both internally and for our customers or the general public: intervening on a system (IoT) already installed at a customer's premises for source code level bug fixes or just update the source code running on the microcontroller.

The problem

Recently we had installed a home automation system (which is also connected to the internet) to a client in Ouagadougou in Burkina-Faso (a beautiful country in addition). So ? The customer reported a system malfunction to us and after analysis with our developers we concluded that there was a bug in the source code running on the microcontroller. The problem is that the system is already installed, the customer is in Ouagadougou and our head office is in Cotonou, Benin and anyway our hardware engineers were on leave (no, I'm kidding). Fortunately we had prototypes of the system on our premises and after a few hours of reviews we had fixed the bug on one of them. Now it was necessary to deploy these corrections on the customer's one. This system is not a mobile application (Playstore or the Appstore would have done the trick) for an instant deployment of the corrected source code and it is not a computer equipped with an OS (Windows or Linux) but a system simply equipped with an AVR ATmega microcontroller. What to do ?

The solution

We had decided to do a remote update of the source code. Known by the acronym OTA (Over The Air updates), the OTA in IoT allows to change (update) the source code running on the microcontroller via a wireless link. A bit like WhatsApp which is updated on the smartphone by connecting to the internet, the system installed at the customer's premises will have to connect to the internet on one of our YoupiLab servers, download the code update (bug fix) , install it and continue its operation without human intervention or any machine. This seems like the best decision since we wouldn't have to bring the already installed system back to our premises, the customer is free to move around as well as our engineers and the base system is connected to the internet.

Work

Our goal is then to connect our system to a server and to retrieve the new source code and to change the one already running by the latter: to proceed with the update. So two tasks:

- A server that will store new updates or bug fixes each time

- A code capable of managing the update on the hardware side (system, hardware)

- A means of storing new and recent source code for possible downgrade / rollback to old source code.

Obviously we are not the only ones to encounter this problem, other IoT companies like us are facing this situation and offering solutions. This is the case of:

- OTA Updates available for ESPs where the module retrieves the update from an HTTP server via a Wi-Fi network and thanks to the ArduinoOTA library updates the code.

The following

We have just started this project and are at the stage of collecting resources to get an idea of ​​what has already been done in this direction. The next step is therefore to start writing the arduino source code which will allow a system equipped with the GSM module, for example, to retrieve the binary source code (.bin) and then update the code on the microcontroller. So see you soon for the progress on the subject.

Comments (0)

Sign in to react to this article

You must sign in to your YoupiLab account to post comments on the blog.

No comments have been published for this article yet.

Stay in touch

Follow us on social media