Upgrade firmware by end-user

[VEGETA]

Hello,

for making a product and you then need to make user update it via USB or SD card but preferably USB... what is the easiest way to do it without much software skills? of course, the firmware should be protected from people flashing it to their own MCUs or so.

I have or plan to deal with these 3 MCUs in preferable order:

1- RP2040 in Pi Pico configuration programmed via Arduino IDE and software: I believe you can press the button then it became a USB device where you drag and drop your firmware and it will be done... but how to make it only work on my own boards?

2- PIC MCUs: I have some experience using 8-bit PICs and have PICKit3. Never done very big software with it.

3- STM32: being very popular and nice market share... looks easier than other MCUs besides 2 above.

for your kind opinion on this, notice that all I require from the MCU to do is just I2C commands + flashing some LEDs or some output signals, nothing big. thus I need MCU to be as cheap as possible.

best regards,

[thm_w]

You'd have a button on your board that you can press to enter the USB bootloader. Or some other way to trigger that signal.

RP2040:
https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf
https://learn.sparkfun.com/tutorials/rp2040-thing-plus-hookup-guide/uf2-bootloader

The second resistor (R1) is a 1kΩ resistor, connected to a header (J2) labelled 'USB_BOOT'. This is because the QSPI_SS pin is used as a 'boot strap';
RP2040 checks the value of this I/O during the boot sequence, and if it is found to be a logic 0, then RP2040 reverts to the BOOTSEL mode, where RP2040 presents itself as a USB mass storage device, and code can be copied directly to it.

STM32:
Depends on the part if it has USB support or not.
https://community.st.com/s/article/How-can-I-use-stm32cubeprogrammer-to-access-the-usb-dfu-bootloader-on-my-stm32-board

PIC: no idea

[VEGETA]

You'd have a button on your board that you can press to enter the USB bootloader. Or some other way to trigger that signal.

RP2040:
https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf
https://learn.sparkfun.com/tutorials/rp2040-thing-plus-hookup-guide/uf2-bootloader

The second resistor (R1) is a 1kΩ resistor, connected to a header (J2) labelled 'USB_BOOT'. This is because the QSPI_SS pin is used as a 'boot strap';
RP2040 checks the value of this I/O during the boot sequence, and if it is found to be a logic 0, then RP2040 reverts to the BOOTSEL mode, where RP2040 presents itself as a USB mass storage device, and code can be copied directly to it.

STM32:
Depends on the part if it has USB support or not.
https://community.st.com/s/article/How-can-I-use-stm32cubeprogrammer-to-access-the-usb-dfu-bootloader-on-my-stm32-board

PIC: no idea

for RP2040, looks like I cannot do an encrypted firmware, thus .hex file can be installed on other boards.

for STM32, assume it supports USB... how can i do it in a way that it does not require the user to get any tools. just hook the board to a USB flash which contains the firmware and it flashes. or at least via PC software.

[mariush]

For PIC, if it has usb functionality and if you have enough space in your code  for the functions, you could probably have it show up as a mass storage device formatted as fat12 or fat16.
User could copy the firmware onto this mass storage device and then after a reboot, the microcontroller would check integrity of that file and flash itself to the newer firmware.

If you need space, a 256-512 kit eeprom is under 50 cents.

ex. user holds down a button while turning on the device to put the device into mass storage mode. The microcontroller shows up as mass storage device and treats at 256kbit/512kbit/1mbit eeprom as a bunch of 64-128 byte sectors ( ex 512 kbit = 64 KB = 1024 sectors x 64 byte per sector).
User writes FIRMWARE.BIN in the root folder of the drive and restarts the microcontroller.

The microcontroller scans the eeprom, looks for a firmware.bin file, checks the header for a signature, maybe a crc16/adler32/crc32 checksum (and if present calculate the checksum of the file and compare it with the checksum in header, and if all is good, load the flashing firmware function and overwrite the stuff in the microcontroller with the firmware.bin contents.
You may want to make a sort of loader for the pic, so that these usb mass storage and programming functions are always in a fixed region of the microcontroller memory and never overwritten by default (just in case power is lost while programming the microcontroller (copying from eeprom to microcontroller) - if the loader doesn't detect a firmware in the eeprom or it's an old or current version, it just jumps to some specific address and run existing code.


Without usb functionality, it may be cheaper to just send an eeprom soldered to a basic pcb adapter (like a SD card) - by the time you consider how big of a space a sd slot takes, how much it costs to buy that sd holder, could just ship the person an eeprom chip on a board with a 6-8 pin header or even just bare pcb pads, and insert the pcb into a slot.

see AN1003 USB Mass Storage Device Using a PIC® MCU  http://www.t-es-t.hu/download/microchip/an1003a.pdf

[thm_w]

for RP2040, looks like I cannot do an encrypted firmware, thus .hex file can be installed on other boards.

for STM32, assume it supports USB... how can i do it in a way that it does not require the user to get any tools. just hook the board to a USB flash which contains the firmware and it flashes. or at least via PC software.

Yeah, although I wouldn't worry about that if its a simple design. If the product gets cloned move on to something else.

For STM32 the user needs software DFU program. They don't need any physical tools.
If you want it to show up as a USB disk, then you have to add another USB bootloader on top (eg: https://github.com/sfyip/STM32F103_MSD_BOOTLOADER )

[dobsonr741]

of course, the firmware should be protected from people flashing it to their own MCUs or so.

If you are serious about this ask then you are in trouble. It’s not coming out of the box and can be a lot of effort.

How much is it worth to you to implement this protection, or in other words, how much you loose without it?

If you have that ballpark there are solutions and risk tradeoffs.

[VEGETA]

If you need space, a 256-512 kit eeprom is under 50 cents.

either this or I get big enough PIC.

is there any code example I can see?

I have never written a bootloader, and I am not skilled as programmer.

The microcontroller scans the eeprom, looks for a firmware.bin file, checks the header for a signature, maybe a crc16/adler32/crc32 checksum (and if present calculate the checksum of the file and compare it with the checksum in header, and if all is good, load the flashing firmware function and overwrite the stuff in the microcontroller with the firmware.bin contents.

seems about what I imagined, the user just have to connect it to his PC via USB and so on then it flashes. this firmware.bin can it be secured to never easily flashed to other MCUs which do not have my code in them? or maybe the cloner will just copy the firmware directly off the MCU chip itself on board... 

I imagine I just finish my code then add this bootloader or library (hopefully provided by MCU manufacturer) then flash the MCU with it.... I see some products provide a simple PC software which gives the update to the product via USB and was hoping to know the method used.

Yeah, although I wouldn't worry about that if its a simple design. If the product gets cloned move on to something else.

won't be simple or complex. it will use ADV7800, ADV7343, and possibly IT6613 which are all for video. but next i could be working on a bigger project which involves controlling ADV7800 with a video scaler ASIC, which is my main concern. such video asic chip can't be purchased but from manufacturer so no cloner can get it. i just don't want to make cloning the firmware easy for them.

If you are serious about this ask then you are in trouble. It’s not coming out of the box and can be a lot of effort.

How much is it worth to you to implement this protection, or in other words, how much you loose without it?

If you have that ballpark there are solutions and risk tradeoffs.

here is a link for firmware update for a product: http://www.micomsoft.co.jp/xrgb-mini/XRGBminiV2.04E.zip

looks like it is either connected as USB device to PC or the firmware is put on sd card.

is this firmware update way seem ok? i mean, is this the traditional good way of doing things?



also, here are instructions from another product:

Instructions

1. Download the FTDI D2XX Drivers and install.

2. Download the RetroTINK Firmware update tool and install by unzipping and running RT_FWUP.

3. Download the appropriate HEX file from above for the desired version and device that you own.

4. Plug your device into your computer's USB port while holding down the 'INPUT' button. The LED should be RED indicating update mode.

5. Run the RetroTINK Firmware Update tool. The installer will have left a shortcut on your desktop.

6. Hit 'Search'. You should see 'FT232R USB UART' appear in the box.

7. Hit 'Load HEX' and point to the .hex file you downloaded.

8. Hit 'Flash'. The update process should start. If the window freezes, that is okay - the update should complete within a minute or so.

9. Your device should reboot and be ready to use.

10. If you accidentally interrupt the process, just start over from step 4.

seems this one uses hex files, but with his own pc software which has "anti-piracy measures" in the firmware.

[mariush]

Well, that product has an extra chip on the board, which is a USB to Serial chip ... so the microcontroller doesn't have any USB functionality built in, and communicates with the chip using plain serial, leaving the complexities of the usb to the usb-serial chip.

It's not as user friendly as showing up as a mass storage device with a drive letter in Windows, allowing you to copy a file there... but it's much less complex. With mass storage device you also need to read the fat table and account for possibility the firmware file may be fragmented (not written in continuous chain of sectors), so it's more code.  With serial communication and your custom programmer, you can control everything and make it more interactive if you want to, but it could cost more (the usb to serial chip is not free)

The "loader" in the microcontroller switches to programming mode and enable serial when that input button is pressed at startup and waits for the programmer to talk to it.  It will receive the binary data encoded as HEX or base64 or raw bytes, buffer maybe 128 bytes at a time by filtering the newlines or anything that's not 0..9 A..F if hex is used or 0-9a-zA-Z and some chars if base64 is used, converting 16 bits at a time to 10-12-14 bits the PIC expects...

The loader may parse a header at the start of the hex dump which could contain an encryption key ex AES128 or something easy to do by a microcontroller - see http://ww1.microchip.com/downloads/en/AppNotes/00821a.pdf as an example-  you'll have a private key hardcoded in the bootloader that's obfuscated or made hard to retrieve in some way and the loader can use the private key from internal memory and the public key in the firmware header to decrypt every packet that comes in.

You could write your own programmer, which could for example enumerate all the serial ports and send a "ping" to each serial port and see if the microcontroller responds with some signature your programmer would recognize.

Then your programmer could send data packets to your microcontroller loader like for example a command

INIT/PREP v=major.minor id=[unique key for your program, to prevent wrong firmware upload] key=01ABCDEF...  (version of new firmware, decryption key) force=false|true (if true, ignore version and force programming)

then loader responds with READY or some response your programmer would understand or it could refuse if the program ID is wrong, or the version is older than existing version and force is false.
Then your programmer could send packets one at a time, like for example
PROG[size 1-2 bytes][offset/chunk id = 2-4 bytes][crc16/crc32/adler32 - 2-4 bytes][data bytes] , programmer would buffer this in ram, calculate the checksum to make sure it was transferred correctly or not,  respond with RETRY/RESEND if not, if all OK decrypt on the fly and program the flash block with those n bytes of data at specified offset, and respond with OK or some message telling your programmer that the particular chunk of firmware was written in the microcontroller memory.
When done, the programmer could send a "RESET" command and your loader would reset the micro.
 
Could also do the reading for backup purposes like send a command INFO or something to get version (major, minor) , size of code, and then your programmer could send the INIT/PREP command to pass the AES key, then loop through a bunch of READ[size 1-2 bytes][offset/chunk id = 2-4 bytes] and your loader could reply with a message like DATA[size-2 bytes][offset2-4 bytes][data bytes][checksum 2-4 bytes]   (checksum at end because it's calculated on the fly as the data is encrypted using the internal key and the key sent using the INIT/PREP command.  This way you'd dump the firmware without it being decrypted at any point.

But note that usually it's quite difficult to keep a private key hidden in a bootloader. It's enough for someone well motivated to do some xrays or use acid to remove the black epoxy and read the memory some way to get the raw code.

some more reading :

AN851 : A FLASH Bootloader for PIC16 and PIC18 Devices : https://ww1.microchip.com/downloads/en/appnotes/00851b.pdf
AN1157 : A Serial Bootloader for PIC24F Devices : https://ww1.microchip.com/downloads/en/Appnotes/01157a.pdf
AN1310 : High-Speed Serial Bootloader for PIC16 and PIC18 Devices  : https://ww1.microchip.com/downloads/en/AppNotes/01310a.pdf
AN1388 : PIC32 Bootloader https://ww1.microchip.com/downloads/en/Appnotes/01388B.pdf

etc


look up other application notes about programming internal flash memory

[VEGETA]

Thanks for extensive post.

looks like it is going to be complicated software to set this up.

if eventually after choosing USB capable MCU I can just copy and paste the new firmware... then it will be ok for anyone to flash it to another chip of his own right?

also, if this is the case, then using RP2040 in pico configuration seems easiest since it has that feature built in.

I hoped to see stuff in mplabx to auto configure it if possible.

[dmills]

I do this on a PIC32 based product, in the fairly standard way.

I have a boot loader that runs at startup, does a CRC on itself, on the main program space, on the off chip flash, checks if a button if pressed....

If any of the CRCs fail, or if the button is pressed at startup it copies the file from the USB stick into the off chip flash (So that a partial file doesn't stomp the existing main program) then decrypts it using a key programmed into the boot loader, checks the CRC, erases the main program space and flashes the new code into the PIC.

The bootloader write to flash routine is designd so that it cannot overwrite the bootloader itself, to minimise the chance of bricking the thing back to needing factory programming, and is extremely paranoid, CRCs everywhere.

You typically need to write a couple of linker scripts to get the two projects to coexist, and there is usually some cursing involving relocation of the vector table, but it is mostly just C. 

Yea, I can think of ways to retrieve the key, but locks exist to keep honest people honest.

Much the same thing would work on an STM32, or probably that Pi based thing (Not that I have used one).

[VEGETA]

I do this on a PIC32 based product, in the fairly standard way.

I have a boot loader that runs at startup, does a CRC on itself, on the main program space, on the off chip flash, checks if a button if pressed....

If any of the CRCs fail, or if the button is pressed at startup it copies the file from the USB stick into the off chip flash (So that a partial file doesn't stomp the existing main program) then decrypts it using a key programmed into the boot loader, checks the CRC, erases the main program space and flashes the new code into the PIC.

The bootloader write to flash routine is designd so that it cannot overwrite the bootloader itself, to minimise the chance of bricking the thing back to needing factory programming, and is extremely paranoid, CRCs everywhere.

You typically need to write a couple of linker scripts to get the two projects to coexist, and there is usually some cursing involving relocation of the vector table, but it is mostly just C. 

Yea, I can think of ways to retrieve the key, but locks exist to keep honest people honest.

Much the same thing would work on an STM32, or probably that Pi based thing (Not that I have used one).

is this supported in mplab x code-configurator? since i saw some posts about a bootloader there. how easy it is to make such key and order the bootloader to take new program and install it?

pi pico requires just pressing a button before boot to go into bootloader, which makes it behave like a flash device. then user dumps new firmware from pc to it via usb. is this the case for you?

[peter-h]

I've done this feature by creating a filesystem in an SPI FLASH (FatFS, FAT12, 2MB) and implementing USB MSC removable storage device profile, which appears (using the STM supplied driver, which on windoze versions above v8 downloads over the internet automatically) as a VCP (say COM3).

You then drop a firmware file there and reboot the product. The file is obviously encrypted and CRCd etc etc to stop trivial disassembly, or accidental corruption. It uses a RAM resident loader which programs the entire CPU FLASH, optionally with the bottom 32k not touched (brick proof mode) or the whole lot (brick time window is ~500ms).

The product also has an HTTP server which I wrote (uses LWIP and the 32f417's ETH subsystem) and that has filesystem access too so one can do the firmware update remotely, subject to login credentials etc.

This as you can guess is all nontrivial and took me months to do. I posted loads of stuff on the various parts which you can find if you search for my threads

Unfortunately anything which works "nicely" takes a lot of time to do...

The other way is the crude one of using the 32F's bootloader mode which (in specific chips) supports USB and it may be possible to get this to work with a PC without any adaptor but I have never tried this. Obviously, no security, and you are supplying a binary file which anybody can disassemble. And it requires user participation at the product, to enable the boot mode.

[VEGETA]

I've done this feature by creating a filesystem in an SPI FLASH (FatFS, FAT12, 2MB) and implementing USB MSC removable storage device profile, which appears (using the STM supplied driver, which on windoze versions above v8 downloads over the internet automatically) as a VCP (say COM3).

You then drop a firmware file there and reboot the product. The file is obviously encrypted and CRCd etc etc to stop trivial disassembly, or accidental corruption. It uses a RAM resident loader which programs the entire CPU FLASH, optionally with the bottom 32k not touched (brick proof mode) or the whole lot (brick time window is ~500ms).

The product also has an HTTP server which I wrote (uses LWIP and the 32f417's ETH subsystem) and that has filesystem access too so one can do the firmware update remotely, subject to login credentials etc.

This as you can guess is all nontrivial and took me months to do. I posted loads of stuff on the various parts which you can find if you search for my threads

Unfortunately anything which works "nicely" takes a lot of time to do...

The other way is the crude one of using the 32F's bootloader mode which (in specific chips) supports USB and it may be possible to get this to work with a PC without any adaptor but I have never tried this. Obviously, no security, and you are supplying a binary file which anybody can disassemble. And it requires user participation at the product, to enable the boot mode.

this seems like the pi pico i mentioned, except that you have it encrypted.

can't this be implemented using mplab x or standard stm32 cube libraries with minimal coding? even if it is not perfect. all needed is a small protection, not necessarily perfect one. so that if one tried using say pickit5 or stm32 programmer to read the device it won't work well with him.

for my particular project it seems more safe since my code is mainly i2c commands with the main chip requiring nda and licenses, so impossible to obtain for cloners.

but i wanted to know an easy way to implement this for other projects.

i appreciate if you have example code for doing this + protection. I need to study such stuff, since i couldn't find tutorials for it.

[peter-h]

standard stm32 cube libraries with minimal coding

Hmmm, no

i appreciate if you have example code for doing this + protection. I need to study such stuff, since i couldn't find tutorials for it.

It's a lot of work. As I said, dig up my past posts here. I have posted a lot (I know it pisses off a few people) because I learn and it helps other people.

Most code on the internet doesn't actually work. Well, a lot of it works partially.

[agehall]

can't this be implemented using mplab x or standard stm32 cube libraries with minimal coding? even if it is not perfect. all needed is a small protection, not necessarily perfect one. so that if one tried using say pickit5 or stm32 programmer to read the device it won't work well with him.

If your goal is to slow down (yes, slow down, not even close to preventing) clones, you might as well give up. Cloners in China are very good at picking things apart and nothing less than a top notch system will not even make them blink, it will only complicate your life and the life of any real, paying, users.

Either hire someone to do this for you properly or just live with the fact that it will be cloned if the product is worth cloning.

Sorry, but this is the harsh reality.

[peter-h]

It does depend on whether your product draws attention.

Firstly it depends on whether it is B2B or retail.

B2B is generally fine because few companies will buy bootleg stuff.

Retail depends on whether marketed directly or via channels like amazon. If you sell mail order then the product may not draw attention for years. If you sell via amazon or ebay, it will, and these channels are packed with counterfeit items. But only if there is volume.

Many previous threads on this.

If you want to make a cheap thing then you won't be paying $2 for an SPI FLASH chip, and implementing FatFS in the CPU FLASH is going to be wildly slow at best (I've seen it done). It won't have ETH or WIFI or BT... You probably want to use the boot loader method. Never used it myself though. You probably don't want to post the firmware on your website

[DavidAlfa]

Stm32 is the easiest using embedded bootloader in USB DFU mode.

[nctnico]

Stm32 is the easiest using embedded bootloader in USB DFU mode.

STM32 is certainly not the only option. There are others that support this. NXP for example. But both won't support encrypted firmware uploads.

I have developed a framework that allows to do updates using AES256 encrypted firmware images. Not available for free though.

[ejeffrey]

It does depend on whether your product draws attention.

Firstly it depends on whether it is B2B or retail.

B2B is generally fine because few companies will buy bootleg stuff.

Retail depends on whether marketed directly or via channels like amazon. If you sell mail order then the product may not draw attention for years. If you sell via amazon or ebay, it will, and these channels are packed with counterfeit items. But only if there is volume.

Right but simply encrypted firmware doesn't help in any of these cases.  If the goal is to prevent cloning then you should either put in the serious amount of effort in both the software and hardware design to make it actually hard to clone or not waste time and money developing something that will be easy to bypass if there is a market for it

There are other reasons you might want encrypted firmware, but preventing cloning requires a lot more than this to even slow people down.

[VEGETA]

There are other reasons you might want encrypted firmware, but preventing cloning requires a lot more than this to even slow people down.

what other reasons?

____

So to sum up, we concluded that micro controllers with USB capability can load firmware easily by say making a button press before powering up then it goes into boot mode to get firmware. the hard thing is protection against copy.

notable MCUs are RP2040 from Pi, STM32 and PIC with USB feature, plus others of course. if this is the case, then RP2040 seems like my best choice due to how easy it is to use in Arduino IDE and since I won't be doing anything besides I2C commands and some GPIO on off stuff. I am worried about if I have a .c and .h files (api) from certain chip manufacturer which I just need to write I2C drivers and use the main.c they provide... I am afraid if in arduino IDE i can't deal with it easily.

____

I see that some MCUs are harder to copy than others, like Renesas ones. is it correct? I remember me and a friend tried to copy its firmware but failed while successfully copying AVR and so on. However, Renesas stuff I feel they are not so popular like PIC or SMT32.

____


at least can we do this: design a simple PC software which is only one .exe file which has the firmware images inside of it, and make it connect to usb to flash the board.

[peter-h]

I have developed a framework that allows to do updates using AES256 encrypted firmware images

You still have to store a decryption key on the chip, so one is limited to how good the security is. Most chips are not good enough against a determined attacker, but if you don't have a multi million $ product...

I used TinyAES which takes up about 1k of FLASH and decrypts at some 100kbytes/sec (aes256, 168MHz arm32).

Right but simply encrypted firmware doesn't help in any of these cases.  If the goal is to prevent cloning then you should either put in the serious amount of effort in both the software and hardware design to make it actually hard to clone or not waste time and money developing something that will be easy to bypass if there is a market for it

If someone cracks the chip security and can disassemble the code, not much one can do. But otherwise, one can frustrate a straight copy being made if more than one programmable device is present.

But we don't know the risk here, so this is repeating many previous threads.

And firmware updated might not be needed. They will be needed only if you screwed up v1.0

[ejeffrey]

There are other reasons you might want encrypted firmware, but preventing cloning requires a lot more than this to even slow people down.

what other reasons?

To keep people from installing unauthorized or modified firmware on genuine hardware.  This is common if you use firmware to lock features, or if you have regulatory requirements like regional locks on radio band use.  Of course, people can still bypass it -- see all the people figuring out how to unlock oscilloscope bandwidth.  But this does fit the mindset of "locks are to keep honest people out" -- some of your users are going to go to the trouble to hack the firmware, but some won't and you aren't fighting against a commercial cloner who is going to copy your product and sell it on amazon.

[ralphrmartin]

The microcontroller scans the eeprom, looks for a firmware.bin file, checks the header for a signature, maybe a crc16/adler32/crc32 checksum (and if present calculate the checksum of the file and compare it with the checksum in header, and if all is good, load the flashing firmware function and overwrite the stuff in the microcontroller with the firmware.bin contents.

A safer approach in case of issues like power loss is to allow for 2 alternative firmware files A and B. If the current running firmware is from file A.bin, flash to file B.bin and after verifying file B.bin was written OK, update a bootloader flag to say file B.bin is the new current version, and vice versa. If the current file ever fails to boot, and you can detect that, you can fall back to the other alternative. In manufacturing, put the same firmware in both A.bin and B. bin so this will work out of the box.

[Silenos]

If you really want truly secure, upgradable only with signed encrypted binary, non-clonable, non-glitchable, non-exploitable, non-rollback-able, recoverable and non-readable by Chinese... services, plus maybe things like license registration and with possible remote trigger/tamper=brick mechanism mcu-based device - you have to support them all - which most are a total clusterfuck to implement, to support in devops, production, transport, presale and postsale.
Plus you need devices which actually really have real "security features" like "secure" boot/flash/otp flash for unique private keys/cert leaves, and it is actually asserted by 3rd party "security expertise" companies that this exact device really works as stated in the advertisments. Not even mentioning resistance to electrical/mechanical dissasembly/scanning attacks. And yes, this should apply by default to every device, not even upgradable one, just to render its software very difficult to rip.
But things like STM32F1/F4 and some other STMs are leaky af, dunno about other PICs,AVR,RP and other older, popular devices.
Unfortunately those "security" features are "popular" for only several years. And since I had an assignment which involves security I'm really not happy about my prior devices.

[peter-h]

Renesas stuff I feel they are not so popular like PIC or SMT32.

Having used a Hitachi/Renesas H8/3xx CPU for > 25 years in another product, I think the above is largely cultural. It is true currently and in the West. In Europe especially STM is popular, due to French origins and lots of people using it. The Japanese lost a lot of visibility since 20-30 years ago.

But Renesas are in business for the long term and often run chips for 20-25 years. They just don't have so many distis... Recently I have designed-out Maxim chips from almost everything and moved to some Renesas ones, which were 1/3 of the cost and very available.

the hard thing is protection against copy.

You could have the USB boot loader mode, but change the boot loader code so it keeps the bottom 8k or so untouched. I don't know if any existing loader can do that (i.e. is the code in something like intel hex, or does the loader just always program the CPU FLASH from the bottom). If you can do a fixed boot block (I have done that) then your distributed firmware can be encrypted.

And you can piss off attackers by using a BGA package and a 4 layer PCB with tracks on the inside and planes on the outside