Upgrade firmware by end-user

[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.