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

[SiliconWizard]

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

That's a good point.
People are so used to buggy software and constant updates that the thought of a device that can't be updated makes them very uncomfortable.
But not providing end-user firmware updates is actually a viable option in many cases.

You have to determine whether spending time developing a means for the end-user to update the firmware, with all the risks (like bricking the device, leaked firmware, etc) involved and the support you'll have to provide for this is worth it compared to spending a little more time testing your firmware so you release something reasonably robust and call it a day.

Of course there are products for which this model wouldn't work, but it's worth at least considering the question.

[Peabody]

I think there has been some progress on the security front in recent years, often involving some kind of hardware secure element chip.  This Digikey article mentions both Renesas and ST:

https://www.digikey.com/en/articles/the-anatomy-of-security-microcontrollers-for-iot-applications

I think you do need to provide for updates, if possible even automatic updates so the customer isn't bothered.

[peter-h]

The thing is that if they made the existing chips without "features" which enable their security to be broken, you would not need this other fancy stuff. You could just store the decryption key in the firmware (probably in a never-modified "boot block") and then your only task is ensuring that nobody inside your company leaks it. Usually somebody will but maybe not for a few years (see e.g. the secured inkjet cartridge case; IIRC somebody inside Canon leaked an RSA private key).

I get the impression the OP is trying to do this for a few bucks.

Setting up OTA firmware distribution is nontrivial. We have done this lots of times and it is really off topic here (we know little of the OP's requirements) but it is an opportunity to destroy your company if it goes wrong. For that reason the phone makers stagger the OTA updates, starting with the "poor" countries and moving to the rich ones after some months. You will want to do the same, but probably by S/N range, and very likely excluding units sold to a particular large customer because if he gets a problem he will see the entire size of it, and will have the power to destroy you. Small customers can be quickly sorted and will be happy, and a customer who had a problem and had it quickly sorted will be more loyal than one which never had a problem. Whereas a large customer, bound up with internal politics and full of corporate ladder climbers, will quite likely just move to f**k you. Been there, seen it... So you need to track serial numbers and which customers got them. All this means there is a lot of nontrivial IT stuff which needs to be set up if you really want automated OTA updates.

Also due to marketing "we want security even if we know f**k all about it" reasons you need to do OTA over HTTPS so your CPU needs to be running TLS as well as TCP/IP and this is a lot of code. My 32F417 is pretty well full, with MbedTLS stealing ~50k...

In my product I was going to implement OTA and it can still be done but the initial plan will be to sell it in a working condition and send a firmware file to anybody who has a problem.

We looked at setting up the update server and the rest of it and it would have cost about 50k. I already have some servers set up (for totally unrelated stuff) and it would be just a standard virtual server, a tenner a month or so, centos/nginx or such, but there is a lot of work in the detail. And if that update server gets hacked, you are totally buggered This IT project is gonna cost you 10-20k a year even if it works perfectly for ever; that's the nature of server admin.

Then it gets better If your box sells loads, and sells to big customers, you need to set up a redundant update server with auto failover.

 

[agehall]

Redundancy on the server side is not difficult if you have a half decent networking guy. That doesn’t even cost much these days.

[peter-h]

Great one-liner

You can work for me anytime

But, come on, who runs in-house servers (in this context)?

[dobsonr741]

We came a long way since OP said:

to do it without much software skills?

[VEGETA]

We came a long way since OP said:

to do it without much software skills?

hhh yes, but this is what electronics forums are for.

I took their advise to never worry about protection and just use RP2040, it allows installing firmware via USB very easily.

since as mentioned, even if I use PIC MCU with a bootloader...etc someone with pickit3 or so can easily hook it up and get the firmware right?

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.

so Renesas is more like Fluke, they keep their products running for +20 years with high quality?

I remember those washing machines I and my cousin worked on had something like UPD78 microcontroller from Renesas, it had no programmer compatible with it as I remember. Some Russian\Ukrainian guy we got to know sells tools or software for getting washing machines firmware and so on but don't remember if it includes this renesas one.

which got me thinking is renesas that good in terms of security or maybe not-so-straightforward to copy?

I saw their website and got lost with multiple IDE, programmers, etc... let alone the huge prices. that alone makes cloners go away xD.

[dkonigs]

If you want it to be easy for the end-user to install firmware updates, without needing any special tools or software, I'm a huge fan of the UF2 format.  You basically start the device in "bootloader mode" (by holding down some button during power-up), and it appears as a USB disk to a computer you've plugged it into.  Then just drag-and-drop the firmware file to it, and it updates.  There's even the TinyUF2 project which provides a great starting point for implementing this.

By having control over the bootloader process, which built-in vendor bootloaders won't give you, you can even do things such as validate the firmware image and ensure that only the data you want can get installed onto the device.

Of course the problem is that this isn't a drop-in/no-real-effort solution on your part.  You'll probably need to make a lot of modifications to the reference TinyUF2 code to make it work well with your platform, and you'll need to fiddle with the build process of your main firmware to get output in the format you need.

On the flip side, there are also approaches where your device can read some sort of user-provided storage device (USB memory stick, microSD card, etc) and install firmware updates off that.  I've personally done both, depending on what makes the most sense for the specific device.

[VEGETA]

Pi Pico RP2040 supports UF2 by default, nothing else needed.

so user can just drag and drop the firmware after booting into bootloader as you mentioned.

[peter-h]

Yes; this is a great way, and it is what I have.

2 possible files dropped
- file1.bin - updates just the main part
- file2.bin - updates boot block as well (brickable but the brick window is under 500ms, and it does loads of checks beforehand)
(not the actual filenames)

But you need a CPU which supports USB, and you need working code to implement USB MSC device profile. The STM chips are not hard for MSC to work (CDC is much more work to get the bugs out).

Then you need code which implements a filesystem in "some FLASH". This can be FAT12 (done nicely with FatFS, and that is quite easy) or UF2 maybe?

Then you need some FLASH to use for this. A separate SPI FLASH is the best way (I have that) but costs some $. I have a 4MB Adesto chip... Or you could implement a filesystem in the CPU FLASH, which is a truly shitty approach which is incredibly slow for writing (in the windows host context) but it works, but needs a CPU FLASH which is erasable in blocks and you need enough RAM to hold the largest erase unit.

[VEGETA]

RP2040 uses an external flash to store its program data. 1 MB flash won't cost much and going to 4 MB ~ 8 MB still affordable with huge room to grow.

RP2040 is my current go-to choice for upcoming project since it ticks all the boxes, very cheap + USB support + getting firmware via USB bootloader built-in..etc. plus, really nice and powerful enough for all my intended stuff.

of course, no protection available but won't worry about it.

so I will be using Pi Pico RP2040 bootloader from manufacturer... don't really know if it can be modified to add other features like you mentioned.

on another note, since you have experience doing this... how to add serial numbers into products to show if it had display and so on? do you actually compile the firmware for each individual product and only modify the line in code which has the serial number?

[peter-h]

If you want simple consecutive S/Ns then you need to store a s/n in some flash somewhere.

Some CPUs have a unique code (non-writable) which you can read and generate a sticker from the #, perhaps with a barcode or QR code, but these won't be consecutive so if you need to track which customer got which unit(s) you need to create a database system which keeps track of all that.

My box has a unique code in the CPU, another unique code in a serial SPI flash, and a simple s/n which is programmed during production. I plan to use just the last one for the external label.

It depends what you want, or need in terms of tracking. Some products absolutely need tracking, per customer.

Also remember customers will often peel a s/n sticker off a new unit and stick it on an old one which is out of warranty, so they send the old one (or one they tampered with and broke, or blew up, etc) back for a warranty repair. This is amazingly common and I've had it done by people who I really would not have expected it from!

[Silenos]

Also, did you consider skipping "customer does upgrade" into "customer sends me the device/board/memory in DIP package so I can upgrade it for him"?
From my experience: technicians installing and starting the industrial grade devices aren't usually motivated engineers - so you should not expect them to be computer literates, manualworms and big brain hackers who deal with totally custom device and procedure in a blink of an eye - expect exactly the opposite.
I like the idea of USB MSC behaviour of the device, too. But in reality majority of population couldn't grasp the idea of your ship engine controller device being a pendrive and that pasting files into it causes its upgrade - consider it too.
With "customer does upgrade" you open a can of worms of all these mundane issues, from thinking of how your updater UX should look like, making your updater to run on windows from 32 bit xp to 11, to reserving more manpower in service department to handle the customers who still can't upgrade your device with their company linux laptop - yes, and those people from service department would shove this issue straight to you and your boss. And you would be made the culprit, I guarantee you this.

[peter-h]

making your updater to run on windows from 32 bit xp to 11

USB MSC should work with all.

No custom driver is involved.

https://www.eevblog.com/forum/microcontrollers/defective-usb-host-hanging-up-your-target/msg4678099/#msg4678099
https://www.eevblog.com/forum/microcontrollers/does-this-code-need-interrupts-disabled/msg4643893/#msg4643893
https://www.eevblog.com/forum/microcontrollers/cleanest-way-to-block-usb-interrupts/msg3927776/#msg3927776

[VEGETA]

If you want simple consecutive S/Ns then you need to store a s/n in some flash somewhere.

so i need to generate the firmware differently for each individual unit. like for example open programming ide and change the line from "sn = 1" to say "sn = 2" and flash the device... then move to 3 then 4 then 5...etc. all individual unit by itself.

or assume rp2040 with usb programming method, it would be the same. i need to change the link and compile for each unit.

tracking and so on maybe not necessary for everything.

[peter-h]

Most products have a factory test procedure, a functional test with some debug functions allowing some limited repair, and that is where the s/n is written - perhaps over a uart (a uart is the simplest possible interface).

You may or may not indeed need a s/n. There may be regulatory reasons for traceability, or with a higher value item there is the insolvency law (country dependent) issue where you cannot recover stock (which a customer did not pay for) unless you can prove a direct relationship with the sales invoice, and usually this implies a s/n on each unit.

[VEGETA]

I came to read this: https://forums.raspberrypi.com/viewtopic.php?t=331910

so using RP2040 in Pico it reads the EEPROM's own serial number which is supposed to be unique for each one, and the designer considers this to be the serial number for the product.

so the code is just one code for every unit and it reads the serial number of the flash once it boots, then the designer can read it via the software and display it on screen or anything.

what do you think about that?

I came across another solution which uses dedicated ICs which has serial number of its own but one of them is about 2.7$!

[nctnico]

Using the internal serial number is the easiest way. But even if you want to have your own serial numbers, you don't have to build specific code for each device. Just make sure there is a way to program a serial number into a piece of flash (a few bytes) to program a serial number.

[peter-h]

EEPROM's own serial number which is supposed to be unique for each one, and the designer considers this to be the serial number for the product.

Lots of chips have some unique code in them.

But as I posted above this won't give you a sequential s/n. Whether this matters, only you can decide.

[VEGETA]

Using the internal serial number is the easiest way. But even if you want to have your own serial numbers, you don't have to build specific code for each device. Just make sure there is a way to program a serial number into a piece of flash (a few bytes) to program a serial number.

assume using pi pico rp2040, how can i implement this?

it is programmed by usb as mentioned, drag and drop the firmware and it is done. UF2 is the way to go but can use hex too.

I don't think I can put another file which has the serial number, and if so then people can just replace them.

Lots of chips have some unique code in them.

But as I posted above this won't give you a sequential s/n. Whether this matters, only you can decide.

yes, it is an easy solution but won't be sequential.

[nctnico]

Using the internal serial number is the easiest way. But even if you want to have your own serial numbers, you don't have to build specific code for each device. Just make sure there is a way to program a serial number into a piece of flash (a few bytes) to program a serial number.

assume using pi pico rp2040, how can i implement this?

it is programmed by usb as mentioned, drag and drop the firmware and it is done. UF2 is the way to go but can use hex too.

I don't think I can put another file which has the serial number, and if so then people can just replace them.

You either need to insert the serial number into the hex file * you are using to program your device or have access to it through a serial port or something that allows you to set a serial number.


* Using some kind of script / tool that can manipulate hex files.

[SiliconWizard]

Yes, IMO the "best" approach (when you can afford it) is to provide a "debug"/production interface (via UART or anything else convenient), not accessible to the end-user, that allows programming serial numbers, setting some parameters, executing some tests, etc.

That's a nice-to-have for production purposes anyway. So during the production phase, you would set the SN, possibly some parameters, and run a few specific tests to make sure the system is fully functional. All of this can be automated.

If you can't "afford" this approach for any reason, you can otherwise program the SN using regular "flashing" tools. You don't need to put it inside the same programming file as the firmware. It can be programmed separately, just generate a hex on the fly (or any format that your tool takes) with the appropriate SN at the address you have defined for it.

Or use a unique ID from a chip that provides that instead (as has been already suggested), but if you want to have proper tracing during production, you'll then stiil have to read it and store it in some database (hence you'll need a way of retrieving it, and if you want to automate this, you'll need some interface such as with my first point.)

[peter-h]

is to provide a "debug"/production interface (via UART or anything else convenient), not accessible to the end-user, that allows programming serial numbers, setting some parameters, executing some tests, etc.

The first thing I ever do with a new bit of hardware

[VEGETA]

is to provide a "debug"/production interface (via UART or anything else convenient), not accessible to the end-user, that allows programming serial numbers, setting some parameters, executing some tests, etc.

The first thing I ever do with a new bit of hardware

well, can you such a thing with USB?

like write a very simple UART function to program a serial number. for arduino stuff, we have the serial monitor and others have putty or various software.

so that I connect the board to PC via USB then send command like "SN input" then device asks for it, after that I enter it.

but uart will require another IC which I don't prefer spending money on... and if i designed or used usb-to-uart little adapters then i need to do it when board is still outside the enclosure. benefit of usb is i can use it easily.

and all that should be constant when user upgrades his firmware which will be by dragging and dropping it via USB. this i couldn't figure out.

[peter-h]

can you such a thing with USB?

Yes. My current product does that, but it needs USB CDC (virtual com port) device profile and then a PC can connect to it with some dumb terminal e.g. Teraterm. CDC is a bit of a bastard to get running properly, because there is no bug-free code around for the 32F4 chips, which does flow control etc. Other chips may be better.

Of course if there is issue with the USB hardware, your faultfinding options are only a) visual check and b) chucking the board away.

Hence most use a UART, but this latest thing I am doing uses CDC because the code was originally generated by someone else with Cube MX and he didn't do a "factory test". STM don't offer such code.

uart will require another IC

The CPU will have a TTL-level UART interface so a MAX232 can be a part of your test rig. Zero cost

all that should be constant when user upgrades his firmware which will be by dragging and dropping it via USB. this i couldn't figure out.

Is there no storage elsewhere? Even if so, a 64x16 eeprom (e.g. 93C46) is about $0.08. You can also do tricks with it to piss off counterfeiters.

[SiliconWizard]

Not completely sure I got this thing about the extra iC required, or maybe my suggestion required some more elaboration.
Your MCU probably has  a spare UART connection available? That's just two GPIOs. I understand that if you're using a small MCU with 100% of GPIOs already used, that may be an issue, and in this case you have to become a bit more creative.

Otherwise, just route spare UART pins to a small connector of your liking (can also just be pads and a pogo pin adapter if PCB area is limited), add some minimal protection (like TVS diodes and/or series resistors) if you really want to be super safe.

And then use any off-the-shelf USB-to-UART adapter, that are available in more shapes, forms and variants than you can think of. Absolutely doesn't need any RS232 level shifting, I would actually not recommend it at all if this is a production interface not for the end-user. Just use TTL levels. To make things even better and more flexible, buy an isolated USB-to-UART adapter, those provide isolaiton from USB (which can be a plus) and usually allow providing the target ref. voltage, so you get level shifting as well (useful if your target level is not typical 3.3V.) This will be part of your production tools.

[nctnico]

Putting a TVS and some series resistors on those UART pins is a good idea though to prevent damage during production testing & configuration. Getting a USB to UART with some protection on the pins as well is preferable. A lot of the UART-USB converters don't have this. I ended up making my own USB-UART converter to have a more rugged device which I can plug into any system without worrying about ground levels, half mains AC being present and so on. I sold a few of these to a customer who went through generic USB to UART converters like a kids goes through a bag of candy due to lack of protection on the pins.

[VEGETA]

i think we agree on UART method of assigning serial number or anything else.

however, assume i installed the firmware (via usb drag and drop method on pi pico rp2040)... and assigned serial number using uart. then the user will update the firmware using usb drag and drop.. how the serial number still not affected despite entire firmware has changed?

[nctnico]

You store the serial number in a flash area that isn't updated. This can be internal (in a flash page that isn't erased during update) or external (eeprom / FRAM). Some microcontrollers have internal eeprom (either real or simulated in flash). First step is to check whether dragging & dropping a file over USB always erased the entire flash or that you can reserve a page / sector.