STM32 code that flashes new code?

[DavidAlfa]

From all the crap I wrote you took the less important part LOL.
Whatever!
+1 to the ignored list.

[nctnico]

If we're talking about the update over the UART, then please note that all STM32 have a built-in bootloader capable of updating.

Just reset the MCU in the bootloader mode (typically, pull boot0 high then reset), and use a standard STM32 bootloader protocol, described in AN3155.

That is how I let more tech savvy customers do software updates as well but for the NXP LCP series microcontrollers together with a standard UART-USB product that acts as a programming interface.

However, for a more universal update method through more convential means like a dedicated update tool, I use encrypted firmware images which also have an SHA1 or SHA256 checksum to make sure the image isn't corrupt. The advantage of SHA1 and even more so SHA256 is that (when seeded with a secret pass-phrase) they are very hard to reverse so your firmware can not be tampered with.

[paulca]

Just popping in.

My STM32 dev board, which I just blew the dust off for a project happens to have an ESP32 on the PCB with the F411.

It's been on my "TODO" list to create an ESPHome component that will flash the STM32 over the air.

I have not even started the research properly yet.  I mean I can do the ESPHome side, but haven't even looked at the STM32 side.

I was hoping to start with someone's basic UART flash bootloader.  Those things people create for their STM32s so they can program them with the arduino IDE or with PlatformIO when they simply haven't spent the $2.99 for an STLink  /mini-rant.

Those bootloaders however should give me exactly what I need, unless they include the arduino core bootloader which won't be.  I just need a bootloader that works like the arduinos.  aka it waits for a time for the UART to connect for flashing and if it doesn't it boots the existing code.

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

[NorthGuy]

Link two copies of application, linked at different memory halves (app_a, app_b; only linker script is different).
Calculate CRCs over app_a, app_b.
Application itself contains code to update the other half.
In the meta section, with CRC, there is also a counter value for each app.
When app_a is updating app_b, it looks at its own counter value and increments it for the other, i.e. app_b.counter = app_a.counter + 1.
Bootloader is a simple piece of code which chooses to boot the firmware which has higher counter value (unless the CRC check fails, in which case it boots the other, of course).

Microchip has this mechanism built-in in their high end PICs. The flash is divided in two partitions. They can be swapped. Config bits select which one boots. Before boot, the one being selected is mapped to lower addresses, while the other one is mapped to the higher addresses. This way, you don't even need different linker scripts.

[NorthGuy]

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

Could've done this with SWD as well.

[paulca]

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

Could've done this with SWD as well.

From the network?

[ataradov]

You can do it directly from the network if STM32 is not required for ESP32 operation.

But even with your scheme, you can substitute UART for SWD keeping everything else the same and get rid of one more component (bootloader).

[NorthGuy]

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

Could've done this with SWD as well.

From the network?

From ESP32.

[peter-h]

I did all this and posted sourcecode here. Search my posts and for stuff like position independent code (which I didn't actually use).

I used bits of the HAL code as examples, and loaded the flashing code into RAM.

And yes a temp copy of the new flash content has to be stored somewhere. I am using an Adesto SPI flash device for that.

I also keep a "boot block" (32k) which is not reflashed, and this prevents bricking. Actually my product does support rewriting the boot block too; there is a "bricking time window" of only about 300ms.

[tellurium]

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

Oh, nice, we did the same years ago, with different target MCUs.
For example, with SAMD51:

[SiliconWizard]

So the SAMD51 was just for flashing the ESP32? Wasn't it actually more expensive than the ESP32 itself?

[n4te]

Using a bootloader to swap between the first and second halves of flash is much better than my RAM copy function. I'll do that in the future!

The discussion has been interesting and entertaining. 

[ataradov]

How it is better?

On SAM D51 it is easier because you have a single bit bank swap. But most MCUs don't have that and you still have to do the work manually. And if you are doing it manually, you can do the swap in the RAM function. It won't be atomic, so you still will get a brick if power interrupts.

[n4te]

How it is better?

It's better than my copy because if the copy fails, the device is bricked until flashed via SWD. Having a bootloader that boots from the first or second half of flash leaves the other half intact. If anything goes wrong, it could boot from the other half and likely still have a device that works.

[ataradov]

If you want to have two images, then you would have to build the application twice for different halves of the flash (assuming no bank switching available). Position independent code does not really work, so you need to different images built for two separate offsets.

Then you can receive the complimentary image over the air and the "bootloader" does not need to copy anything, it just needs to pick the most recently updated half and boot it.

This is also a very common approach in wireless systems.

[SiliconWizard]

How it is better?

It's better than my copy because if the copy fails, the device is bricked until flashed via SWD. Having a bootloader that boots from the first or second half of flash leaves the other half intact. If anything goes wrong, it could boot from the other half and likely still have a device that works.

Yes. Only at the cost of having only half the flash available. Your choice.

[tellurium]

So the SAMD51 was just for flashing the ESP32? Wasn't it actually more expensive than the ESP32 itself?

Nope, vice versa.
ESP32 flashes SAMD51

ESP32 connects to a cloud server, and thus is accessible remotely.
As a result, we got a remotely controllable, update-able SAMD51

[paulca]

The ESP32 component will receive the incoming binary flash stream, reset the STM32, connect to the UART, flash it and reset it.

Could've done this with SWD as well.

From the network?

From ESP32.

Does a viable ESP32 SWD client exists? 

[ataradov]

The SWD part is easy, if you can toggle a couple pins, any MCU can do it. The part that would need work is the actual ST flash programming, which is just following ST datasheet.

Example portable SWD code is here https://github.com/ataradov/embedded-swd . The target code there for SAM D21, so that would have to be adjusted for ST.

[SiliconWizard]

So the SAMD51 was just for flashing the ESP32? Wasn't it actually more expensive than the ESP32 itself?

Nope, vice versa.
ESP32 flashes SAMD51

ESP32 connects to a cloud server, and thus is accessible remotely.
As a result, we got a remotely controllable, update-able SAMD51

Oh ok, I see.

[tellurium]

Does a viable ESP32 SWD client exists?

we have https://vcon.io - that's a closed source pre-built firmware for esp32/esp32c3, which can reflash some MCUs (including all STM32)

STM32 reflashing can be over SWD or UART.
If SWD is wired, a remote GDB debugging is possible  - https://vcon.io/docs/#live-debug-with-gdb
Remote means remote, e.g. your device could be deployed to the customer's premises, and you can debug it from your office.