Best way to update microcontroller firmware for end user?

[gmc]

I've got a open source project I'm busy with which uses a AtMega32u4. I plan on producing and selling a small number of PCB's with this microcontroller which will have a 6 pins  installed for installing the bootloader via SPI. Once that's done I can upload the latest code via usb/arduino ide and then ship out.

The query I have is there will  most likely be a few updates to the code which the end users will need to upgrade to.

What is the easiest/best way to do this. I could just give them instructions to use Arduino IDE, compile and upload the code, or send them the .hex file and use avrdude which might/might not be too technical for them.

What other methods are out there I can look into? Add on a SD card to the project and update from SD Card? Seems the easiest way but probably overkill. Project  cost  will increase and then I need to add a SD card just for firmware upgrades.

Or maybe could the hex file be  wrapped up into some windows application. You connect the PCB to the USB port, run the program and it upgrades?

[Mr. Scram]

I've considered all three options before and it seems all but the SD card option end in a shitfest for the users. You'll have to support all kinds of configurations and it's no fun for the user. Factor in support cost and lost goodwill and the SD starts looking much cheaper. You may want to trawl through my old thread.

https://www.eevblog.com/forum/microcontrollers/user-upgradable-firmware/msg1273355/#msg1273355

[NorthGuy]

Most users will have a phone and an USB OTG cable (I guess). So, they connect the phone to your board and your app downloads updates over the air.

[Mr. Scram]

Most users will have a phone and an USB OTG cable (I guess). So, they connect the phone to your board and your app downloads updates over the air.

Do you have experience supporting this?

[NorthGuy]

Most users will have a phone and an USB OTG cable (I guess). So, they connect the phone to your board and your app downloads updates over the air.

Do you have experience supporting this?

Not really. I wanted to do it, even wrote some pieces. But very few phones supported OTG at the time, so the idea was scrapped.

[Peabody]

I wrote an SD card bootloader for the TI MSP430 microcontrollers.  The user would insert an SD card with the new firmware on it, then power up.  The bootloader would detect the presence of the card, read in the latest file of the correct size, and flash the contents to the chip.  I found that I could make this work without dealing at all with the FAT since files would naturally be stored in sequential sectors.  But this was written in MSP430 assembler, so it probably wouldn't do you much good except to follow the logic, but you're welcome to whatever might be useful.

https://github.com/gbhug5a/SD-Card-Bootloader-for-MSP430

I think you would find that a microSD holder is *VERY* inexpensive, and if you can run your AVR at 3.3V, there would be very few additional parts needed.  And I think you can still find 256MB, 512MB or 1GB microSD cards for a buck or two to include with the device.

You might be able to find an SD card bootloader for AVR.  There appear to be three of them on Github.

This would be easiest for the user because he doesn't need drivers or softwear installed, and doesn't even need a particular operating system.  The downside for you is the need to write the bootloader, and the need to provide power to the SD card, which is often a lot more than the entire rest of the project.

[kripton2035]

I would make a windows-mac-linux app that download and install the firmware in the device, connected to the usb port.
if it is open source, I would also provide the arduino source code so that they could program it themselves.

[mariush]

You could have a simple 5 pin header on the board ... voltage, ground, i2c / spi data and clock and a pin for key (so you don't insert it the wrong way)

Have a 256-512 kbit (32KB+) eeprom i2c/spi on a tiny pcb with a 5pin connector, insert it into the header, boot the device.
Your device does a checksum check of the binary in the eeprom,  then programs the atmega chip, erases the eeprom, reboots ... job done.

Eeprom chips are 20-30 cents if you buy 100... you can sell these as upgrades for 1-2$ on your page, for those that don't want to deal with compiling and programming the eeprom. ex: https://www.digikey.com/product-detail/en/stmicroelectronics/M24256-BRMN6TP/497-6348-1-ND/1827926

You could make a tiny application that uses serial cable / usb-serial to talk to a small micro which takes incoming packets of data and writes them to a eeprom chip (ex take the following 64 bytes and write them at location 0x001234) ... such a programmer can be done on a breadboard. Alternatively,  maybe a jumper or button held down on your board could switch your device into a "programming mode" at boot, so an application could send packets of data which end up written into the eeprom chip and then your bootloader programs it at next reboot.

[gmc]

Thanks for the replies. Some interesting links.

Seems  the easiest for me and the worst for the user is to get them to use Arduino to upload the code.
On the other end of the scale, easiest for user and worst for me is to use a SD card with a bootloader.

[jeremy]

This is something that looks interesting: https://devanlai.github.io/webdfu/dfu-util/

Back when nextthingco still existed, you could reflash the Linux image on their board using just chrome and a USB cable, it was very easy. But chrome only unfortunately.

[fchk]

Just have a look at the NXP LPC1343. This Cortex M3 has got USB drivers in internal ROM, and this ROM also contains bootloaders.

One bootloader implements mass storage. The device then turns into a 32k USB mass storage device. You copy your bin file to it, eject the device, and thats it.

With an Atmega I'd suggest using an extra SPI RAM chip like 23K256 for temporary mass storage use. You can then do checksum checks before even touching the flash.

[Mr. Scram]

I would make a windows-mac-linux app that download and install the firmware in the device, connected to the usb port.
if it is open source, I would also provide the arduino source code so that they could program it themselves.

Do you have experience developing for three major platforms and subsequently supporting the product on all three? Just the first part sounds like a mammoth task. Proper companies fall on their faces with that kind of stuff.

[kripton2035]

I would make a windows-mac-linux app that download and install the firmware in the device, connected to the usb port.
if it is open source, I would also provide the arduino source code so that they could program it themselves.

Do you have experience developing for three major platforms and subsequently supporting the product on all three? Just the first part sounds like a mammoth task. Proper companies fall on their faces with that kind of stuff.

using Xojo for 10+ years I can say yes I know how to build and maintain win-mac-linux apps.

[NorthGuy]

Do you have experience developing for three major platforms and subsequently supporting the product on all three? Just the first part sounds like a mammoth task. Proper companies fall on their faces with that kind of stuff.

I support Windows/Linux/Mac. It's nothing difficult in this. Of course, there are problems here and there. Like Apple decided that only 64-bit software can run on their latest OS, which I didn't anticipate. But that's Ok. The world is changing all the time, you have to adapt.

[MarkL]

I would try to stick with DFU and not add extra hardware.  DFU is already supported by Atmel/Microchip.

Did you try FLIP? :

  https://www.microchip.com/developmenttools/ProductDetails/FLIP

It doesn't support MacOS, but you didn't mention your compatibility requirements.

[ralphrmartin]

Thinking out the box - implement your device on the mbed platform. (Assuming of course, it does not HAVE to be ATMega32u4).

Then it's trivial for the user to reprogram it - they just plug it into a USB port, it appears as a disk (Mac / Linux / PC), and they drag and drop the file you supply to them to the board.

Update done.

Of course, there's nothing to stop them flashing any old binary to it. That's where the "unauthorised upgrades void your warranty" clause comes in.

[ogden]

Write your "wrapper" application for arduino-cli: https://arduino.github.io/arduino-cli/installation/. Your application shall check hardware and firmware to avoid flashing wrong firmware and/or wrong hardware, then ask confirmation of firmware upload, then execute arduino-cli.

[Mr. Scram]

I support Windows/Linux/Mac. It's nothing difficult in this. Of course, there are problems here and there. Like Apple decided that only 64-bit software can run on their latest OS, which I didn't anticipate. But that's Ok. The world is changing all the time, you have to adapt.

I have some trouble seeing how it wouldn't complicate matters significantly. You have to have three development tool chains or find one which does all three and does it correctly. You have to figure out how to test your product on all platforms, which includes a multitude of subvariants and endless software and hardware variations. Just the Windows platform is fairly diverse and Linux takes this to another level. After release people will invariably find all kinds of ways to break your product and exceptions and you're expected to support and fix that too. All that for a firmware update.

It's probably less of a hassle if you already have the tool chains already set up, but it seems less than trivial if you don't already have a fair bit of it set up.

[Mr. Scram]

using Xojo for 10+ years I can say yes I know how to build and maintain win-mac-linux apps.

Can you tell us more about how you do that?

[nctnico]

Change your project to an NXP LPC processor which has the option to act as an attached storage device. Customers can drag & drop the firmware in it. Alternative use any processor with USB support and make it behave like an attached storage device so customer can drag & drop firmware files to it. You'll need to have enough flash in the device though. The upside is that you can encrypt the firmware if you want.

[kripton2035]

Quote from: Mr. Scram on Yesterday at 22:57:25

>Quote from: kripton2035 on Yesterday at 18:50:20

using Xojo for 10+ years I can say yes I know how to build and maintain win-mac-linux apps.

Can you tell us more about how you do that?

all you need is here : https://www.xojo.com/
you can play with it all you want, you need a paid licence only to build a standalone app.

[ogden]

The upside is that you can encrypt the firmware if you want.

Encryption is option for bootloader kind of firmware update as well.

[Mr. Scram]

Quote from: Mr. Scram on Yesterday at 22:57:25

>Quote from: kripton2035 on Yesterday at 18:50:20

using Xojo for 10+ years I can say yes I know how to build and maintain win-mac-linux apps.

Can you tell us more about how you do that?

all you need is here : https://www.xojo.com/
you can play with it all you want, you need a paid licence only to build a standalone app.

I was hoping for some practical experience and what works well and what doesn't, instead of just the manufacturer sales pitch or myself bumbling about. 

[nctnico]

If an application is just for Linux, Mac, Windows then I'd stick to Qt or WxWidgets. Does Xojo support Arm for example so people can run it on an Rpi?

@gmc: Making a seperate program for firmware updates is not the best way forward. Think of all the support you'll need to give. OS updates/upgrades do break stuff so you'll be catching up all the time.

[Mr. Scram]

If an application is just for Linux, Mac, Windows then I'd stick to Qt or WxWidgets. Does Xojo support Arm for example so people can run it on an Rpi?

@gmc: Making a seperate program for firmware updates is not the best way forward. Think of all the support you'll need to give. OS updates/upgrades do break stuff so you'll be catching up all the time.

Their website says "Rapid application development for Desktop, Web, Mobile & Raspberry Pi" so that appears to be a yes.