Easiest way to firmware update?

[EAndr.2]

Hi all!

So I'm looking for the easiest and fastest way to create a firmware update desktop app for an STM32 device (Arm Cortex M7). I would like to have something like CubeProgrammer, but way less functionalities (just programming/flashing). Being a commerciall product for non-programmers CubeProgrammer is not fine. I want something proprietary with my GUI.

So, .... the strategy I found online is to create a custom bootloader (like this: https://github.com/viktorvano/STM32-Bootloader) and control it with a Java app with serial communication libraries.

But why do you NEED a custom bootlader? Can't I just flash to the flash memory (from 0x8000000) and let the default bootloader take care of things? Easier and less flash memory usage.

Security is not the priority. Ease and fast implementation is the priority.

It would really help me to clarify this, please. Any suggestion is welcome.

Anything will do, really, as long as I can upload a .bin (or.hex) file to the MCU through my desktop app.

Thanks!

[Tesla DeLorean]

You can talk to the System Boot Loader, via serial, USB, etc.

The protocols are documented, and you can implement in an OS / Language of your choice.

Problem is that they are designed for initial programming and recovery, and not really user friendly, nor protective of your code. Good for programming cheaply in the factory, and where engineers stand ready to resolve issues.

With your own loader you can use your own protocols, on pins/interfaces you chose, and in a manner that's secure and recoverable.

ie you can encrypt and sign the images, you can validate those before running, and revert to recovery mode if damaged or corrupt.

You can use common protocols like X/Y-Modem with assorted terminal apps, or your own apps that can connect via COM/TTY with relative simplicity.

With SD Cards you can deliver code/updates that way. With Cellular or Ethernet you can use network protocols, have code fetched via HTTP, FTP, or your own TCP/IP socket methods.

The system loaders are designed to be limited, and are not board specific. With your own you can use whatever features they provide. Typically you'd split the functionality in two, a loader and an application. The loader can validate the application, and you can add functionality based on how much flash you commit to each. Also often good to have storage where you can stage the entire update, that way you can ensure integrity before you start, rather than failing mid-way through the process.

A lot of this depends on your comfort level with the host systems your users expect. If you have to write your own device drivers that clearly complicates the task.

[EAndr.2]

Please allow me to clarify that I would like to firmware update through USB only (serial communication).

When you say "The protocols are documented"... which protocols are you referring to? Where can I find this documentation? Can I just write the binary (from desktop commands) from the start of the flash memory and let the default bootloader do its job?

[Tesla DeLorean]

https://www.st.com/resource/en/application_note/cd00264379-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

>>Can I just write the binary (from desktop commands) from the start of the flash memory and let the default bootloader do its job?

There are command line versions of STM32 Cube Programmer, perhaps also do-able via a DLL.

Generally if you want it to be easy for the end-user, you're going to have to do a lot of the work to make that happen.

If you want a USB CDC/MSC implementation you have to implement the USB Device code yourself. There are some examples.

Other IAP examples are in the Cube trees, should be one for a USB MSC HOST, ie taking a FLASH DRIVE, others that demonstrate reading files from an SD Card.

This is the USART protocol. https://www.st.com/resource/en/application_note/an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

This describes the system loader's functionality. https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

[Tesla DeLorean]

In terms of the most universal method requiring little tools, drivers, skill, is a drag-n-drop USB MSC.

A large QSPI NOR Flash could facility easy staging, chips are small, cheap, easy to wire to current STM32 families.

Staging allows for security, integrity, encryption and compression.

[Pavel A.]

Have you looked at the CubeProgrammer API and examples? They are installed in the CubeProgrammer directory. This API lets one (with certain skills, of course) develop an updater using a ST-LINK or the built-in bootloader over USB DFU.

The user will need to install the same USB drivers that come with CubeProgrammer.