Update Firmware over USB Virtual Comm Port

[LMorr.3]

Hello,

I am using the STM32F373's virtual USB port successfully.  I can connect and send packets to the uC from a web browser.  I now want to allow the user to update the firmware from the web browser by uploading a file, instead of the traditional method involving the ST flash software.  

It would need to happen via WebSerial API so over the USB virtual port.  What is the best way to accomplish this?  Is there an appnote I should look at?  I'm looking at AN2606 [bootloader] and AN3156 [DFU] and AN3156 now.

Thank you,

[LMorr.3]

I'm still learning about the best approach.  The USB connection starts off as a virtual com port, and then sends a command to the uC to switch it to boot mode via USB DFU.  That is as far as I got, but I'm guessing there are github projects which will show me how to get the dowload from browser done, instead of using the ST32 programmer app.  The uC would then receive the 'Go' command to get back to running the newly updated app.  I'm surprised there is no well-documented solution to this since it seems to be the most convenient way to upgrade end-user products.  The USB DFU even allows a web URL to be discovered by the host, so the checking of the latest version, downloading of new firmware and flashing could all be done behind the scenes.  I've seen this done with other end-user devices.  I'm not sure if bricking of device is a concern so I still need to do more research.  

[BarryWhit]

> I suppose it should be possible, while your user application is running, to accept a command from the client,

> and then go through some sort of state cleanup followed by a jump to the bootloader. Might work.

Just saw this,

KB:How to jump to system bootloader from application code on STM32 microcontrollers

I still think this is the wrong approach, since the possibility of a failed update means you'll still have to instruct your users on how to access the bootloader independently of your application. But it's nice to know it's possible.

[LMorr.3]

Thanks for the info.  I had to spin up new boards ( to pull-up the USB DM correctly ) so I need to wait to get those before I can try.

I understand what you mean about failed updates.  If the USB DFU method fails, I plan on having instructions for the user to set the jumper to 'boot', and use the STM32Cube programmer app.  ( Direct the user to a web page using the default web URL of USB DFU, where they can download the STM32 programmer app )

I'm wondering though; considering the same data is sent with either method, what could cause the update to fail via USB DFU versus using the STM32Cube programmer app?  

Can the user always recover using the STM32Cube programmer app, or can the STM32F373 sometimes become 'bricked' and un-usable if an update fails?

[BarryWhit]

> what could cause the update to fail

Many users own cats.

If an update is initiated through your application and fails, perhaps due to feline intervention, the user will not be able to try again through your application. They will then arm themselves with pitchforks and twitter and loudly demand that you furnish them with a recovery procedure. If you delay too long in responding, they will first dox you and then SWAT your home. Then they will create attack websites using the very latest AI diffusion models, websites that will portray you as a sexual deviant. And I'm not talking about the trendy, acceptable, kind of perv, either. So you see, It really is best to get the firmware update flow right the first time.

> can the STM32F373 sometimes become 'bricked' and un-usable if an update fails?

A failed update can leave the application flash area in an indeterminate state but the bootloader is held in a separate part of memory ("system memory") which is not touched by a normal firmware download process (it is writable though - you could replace it with a custom bootloader for example. Kind of like android recovery).

It is also possible to roll your own update process with additional safeguards, and many vendors do so. Consider for example the various fail-safe measures introduced by motherboard manufacturers, over the years, to deal with BIOS updates. One common theme is keeping two  copies/versions of firmware side by side, so that the updated version become active only after the update completes successfully, and so the system can fail over to a known-good version if it detects a problem during boot. There are all kinds of variations on this theme as well as other kinds of protections. It all depends on the level of assurance you need. Your typical USB gadget doesn't usually bother.

[LMorr.3]

From what I gather, it's not possible to 'brick' the STM32F373 if the STM32Cube programmer app is used.  The STM32Cube programmer download can also fail under the same conditions, but the user can just re-start the download if it fails.  In my case, I plan on having the web app will persist a 'downloading firmware' state via the browser's localstore, and show a firmware update web page if the state is present, with a link to download the STM32Cube programmer.    ( clear local store upon fresh install/upgrade or successful connection )  The user would need to set a jumper and restart the device.

[BarryWhit]

> From what I gather, it's not possible to 'brick' the STM32F373 if the STM32Cube programmer app 

As they say, give me a big enough hammer and I will make your hard real-time system fail to meet its deadline.

But true, you can try over and over by manually placing the chip into the bootloader and using the programmer software. What I said was that if you use your own software routine to go into the bootloader, that software will not be available for a second try if martians attack the power grid during your first attempt (or the battery dies, etc').

[LMorr.3]

Ok, I built a new board and I see USB device when I run 'dmesg':

[3552008.377434] usb 3-2: new full-speed USB device number 101 using xhci_hcd
[3552008.526223] usb 3-2: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
[3552008.526227] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3552008.526229] usb 3-2: Product: STM32  BOOTLOADER
[3552008.526230] usb 3-2: Manufacturer: STMicroelectronics
[3552008.526231] usb 3-2: SerialNumber: 2077345D2039

 But now when I run the STM32CubeProgrammer, it does not connect to the USB device or even show it listed in the dropdown box.  It shows 'No DFU detected'.

I have set the boot jumper on my board and it does seem to be detected as 'STM32 BOOTLOADER'.

Any ideas on what I could try?

Best,

[BarryWhit]

You best start a new thread for a new issue.