Having a teensy 4.1 update its own firmware?

[wyager]

I'd like to build something that can do OTA firmware updates, with no PC or other controller in the loop.

The way I would do this on a non-teensy setup would be to have a small boot shim at the standard boot address, say 0x1000 (all numbers are illustrative). The boot shim would check both 0x2000 and 0x3000 for a firmware header, and whichever one had the latest version, it would jump to.

Let's say you're running firmware version 4 from 0x3000, and you get an OTA update for firmware version 5. You would write version 5 starting at (say) 0x2004, do an integrity check, and then update the header at 0x2000. Next time the boot shim boots, it would see that 0x2000 has the more recent firmware version and jump there.

Is the teensy set up in a way where such a thing is possible (i.e. where I can update the boot flash without using the teensy loader)?

 

[CollinK]

This might be somewhat what you are looking for: https://github.com/joepasquariello/FlasherX

I have used that code to be able to update a Teensy MicroMod from an SDCard. It is entirely possible to use it for OTA updates as well.

 

[AndyA]

You may also want to look at https://forum.pjrc.com/threads/72233-OTA-through-Ethernet-with-Teensy-4-1 for and example using FlasherX to perform updates over the ethernet interface.

The way this works is that as the new firmware is received it is placed in a buffer, either in RAM or flash depending on the settings (default is in flash). Once the full file is received it is then copied to the normal boot address in flash.
Since it's updating all the code rather than just a pointer to where the code is there is a larger window of vulnerability to power loss. But the current firmware isn't erased until the new one is fully received and passed some basic sanity checks so it's not terrible.

Your planned approach of a small bootloader and a pointer to the location of the main code is more secure and less venerable to power loss at the wrong time. And it can be made completely safe by using things like multiple pointers in different sectors. But it has the down side that you can't just do a normal firmware build and download with the standard tools without some tweeks. The code needs to be built to run from a different address and then uploaded to a different memory location from the default.
The slightly less secure method of replacing the whole code each time means that your code can still use the completely standard build tools/settings and programming methods.