Distributing updates for FDTI without Arduino IDE

Projects General Guidance
1

So here is my scenerio:

I have made a device with an embedded ATMEGA328p on the board, which is loaded with the Arduino boat loader. I put a 5 pin FDTI header on the board, so that i can put a new version of the sketch on the chip without having to uninstall the 328P or to have to put a USB driver on my board. This all works great.

My question is, say I put one of these in the field and wanted a person to update the firmware. Is it possible to distribute a "package" that could be loaded onto the chip with the FDTI cable in a self-contained manner. Otherwise, I'd have to require the person updating to get the Arduino IDE and make the code all open-source. Which, I'm not opposed to necessarily, but I'm wondering if there's a neater, tidier way to do it? Or do I have to bite the bullet and put the USB driver chip on my board?

2

This is more a logistical question before you can select a technical solution.

How do you want to deliver the code?
Do you trust the "customer" with your source code or binary?
Is the customer technically able to program the device?
Do you have a technician that would update the product?
Can you expose connections on your product?
...

There are multiple solutions for the hardware:

  • Use a different microcontroller that can update itself? Needs an interface e.g. SD card slot, BLE, USB, ... and needs more memory
    -- With USB you could create a mass storage device where you just copy the file and the device reprograms itself
    -- The same is true for SD card but you would not need to carry a PC near the board.
    -- With BLE or WiFi you could download the new program over the air. So, the device can be sealed.

  • Create a smart cable that contains the programming circuit and use Arduino IDE. Look at the Arduino Nano Every design. It has a separate SAMD21 microcontroller that handles all the USB and programming stuff.

  • Create a self-contained smart dongle that does not need a USB connection. Circuit similar to the smart cable.

From a software point of view, you can ether send the HEX file to program the device or you can use encryption to make it harder for people to "steal" your software.

3

Klaus_K:
From a software point of view, you can ether send the HEX file to program the device or you can use encryption to make it harder for people to "steal" your software.

If the firmware in the device was built using the Arduino IDE and Arduino libraries the resulting software image will be licensed LGPL 2.1 or possibly even GPL v3 depending on which libraries are used.

A person that buys or has possession of the device, under the licensing terms, has the right to change/modify/update any of the LGPL 2.1 or GPL v3 code in the software image.

It is pretty much impossible to provide this capability to the end user without giving them all the source code.

Long way of saying, if you use Arduino and Arduino libraries, people don't have to "steal" your code, all they have to do is ask for it.

--- bill

4

bperrybap:
Long way of saying, if you use Arduino and Arduino libraries, people don't have to "steal" your code, all they have to do is ask for it.

Good point. Thank you.

There might be other reasons why you would want to encrypt your firmware e.g. to ensure the device is only programmed with a software you have signed. This could be for safety reasons if your product can potentially harm someone or warranty claims.

5

Another thing to consider - do you care if they reverse engineer the board and use whatever convenient programming option you provide, to upload their own custom code?

6

Another option is to supply a Standalone Programmer, then you just need to send out files for the user to put in SD card and load into the unit.

1752×1713 385 KB

http://www.crossroadsfencing.com/BobuinoRev17/

7

There are really several different issues:

  1. Getting s/w updates for the device to the user and getting them installed into the device, i.e. field updates.
  2. How can a user update/modify/change any of the LGPL / GPL code used inside their device?
  3. Trying to prevent users from doing "non official" updates to the device

I'm not sure if #3 is/was a real concern based on the initial post.

From the initial post it seems like the initial concern was for #1,
how to make field updates simple as there didn't seem to be a stated concern of trying to keep any of the source code closed or to prevent non "official" updates.
There are several ways to handle this, and which way is chosen will depend on several factors like cost and physical size sensitivity and how the updates may be distributed and how easy it has needs to be.
The high level requirements will likely drive things in a particular direction.

#2 is an issue that must be considered as it is a LGPL & GPL licensing requirement.
Even for LGPL 2.1 there is still the issue of how to comply with 6(a)
Which requires that a user be able to update/modify/replace any LGPL code used in the image.

For #3
It is difficult to prevent the f/w in an "arduino" type device (or any embedded device for that matter)
from being updated if a user is intent on doing it and has high enough technical skills.

Even if the device doesn't support f/w updates using some kind of bootloader, if the MCU can be accessed by disassembly
a person could connect directly to the MCU pins and use ISP programming to re-program it.

Trying to lock out users from doing their own updates can run into LGPL & GPL licensing issues for projects / products that use LGPL or GPL open source code, particularly if all code is not open source.

The potential issue with putting in measures to try prevent this, like say doing some sort of signature, is that it can end up violating some of the licensing requirements.
It would for sure violate GPL v3 as GPL v3 was explicitly created to prevent this kind of thing after Tivo did this very thing.

--- bill

8

CrossRoads:
Another option is to supply a Standalone Programmer, then you just need to send out files for the user to put in SD card and load into the unit.

You could also use something like a low cost esp8266 or esp32 for the programming.

Run the ESP part in AP mode so no local wifi access to the customer's network is needed.
Then you connect to the ESP Access Point using Wifi and ftp your firmware image to it.
The ESP stores it in the SPIFFS files system and then can use it to update the device using ISP.
You can use tools like filezilla or even a browser, depending on how you write the code on the ESP,
to allow file drag and drop updates or updates using a web browser.

For automatic updates
Have the ESP module connect to the customer's Wifi Network and "phone home" to check for updates.
If there is one, use ISP programming to update the device.
If you use WiFi manager, all the standalone programming devices will be the same and the customer can configure the network access parameters to gain access to an WiFi network with internet connectivity.

There are lots of options available when using standalone programmer.

In the bigger picture, would be be acceptable to use an ESP module instead of a ATmega328?
That module already supports wireless updates.

--- bill

9

Thanks for all the replies! Lots to think about.

For sure, the number one thing that I want to accomplish is to make it easy for someone to update the firmware later on in case I find a bug in it and need to fix it. This is for a music synthesizer module, and mostly my users are very capable on the DIY side of things so they would be able to perform such an update.

I am not really particularly interested in trying to protect my code (other than having people possibly laugh at how amatuerish it s :smiley: :smiley: ) though.

I was just thinking more about keeping the process easy and self-contained, but I suppose downloading the Arduino IDE is not such a difficult thing. And it is free.

And just to be clear, there isn't such a thing as a "Mini Arduino" application that ONLY sends sketches to a board is there? This would probably be ideal. THat way they could just send the program over the FTDI cable and not worry about what is inside it, but they could take the source and edit it and make non-official updates on their own with Arduino if they want to really dig in more (I am OK with this).

10

"Mini Arduino" with updates over FTDI does not exist. We were working on a Pi with small display and a rotary encoder or a couple of buttons for program selection, and got the coding part working, with mouse and a standard display. Battery power would be difficult, a Pi sucks a lot of current.

11

devinw1:
I was just thinking more about keeping the process easy and self-contained, but I suppose downloading the Arduino IDE is not such a difficult thing. And it is free.

While it is free, from time to time there can be issues with IDE versions or the 3rd party libraries that can cause things not to build or create uploading issues.
And various 3rd party libraries have to be installed.
All this can add up to create some support head aches.

And just to be clear, there isn't such a thing as a "Mini Arduino" application that ONLY sends sketches to a board is there?

If what you mean by "Mini Arduino" is something that sends a pre-built image.
Then, "yes" but it isn't called "Arduino".

The IDE calls a tool called avrdude under the hood to do the uploading to AVR devices once the image has been built.
You could use that directly.
For an embedded project I was involved with (The USBASP project)

I created wrapper scripts for avrdude to make it easy to update the firmware in a USBasp device.
(but these scripts are not unique to that device / project)

It allows users to drag and drop pre-built firmware images to update the device on Linux, MAC, and Windows.
The issue you can have is identifying the programming port in the case of using a serial port when talking to an Arduino bootloader.
That is the most problematic for users since it isn't obvious what the port name is, this is particularly difficult on Windows.
Essentially you have to ask the user for it.
This can be avoided by using ISP programmers such as USBasp or USBTiny.
For those ISP programmers avrdude can automatically locate the USB ISP device so the user doesn't have enter in anything.
IMO, this makes the easiest to use user experience as they simply drag and drop a file and the device is updated.

For this methodology, you could provide a downloadable image that contained avrdude, the wrapper scripts, and the firmware image.
The user could drag and drop the file to to the update or you could simply create a wrapper script that just does it.

If you look at the USBasp project it provided scripts and the user could enter in the path for the avrdude tool if it wasn't already on his path.

The more recent IDE versions now can be run from the command line instead of the GUI.
This is the command "arduino-builder" that can be wrapped in script to automate an upload.
If you google around you can find more info about it.

Then there is the tool called "Arduino Builder" which 3rd is a party tool which can do builds and uploads from pre-built images.
It was created before "arduino-builder" exists, but seems to have been maintained up to last year.
I haven't used it but that might be an option.

https://forum.arduino.cc/index.php?topic=151774.0

http://arduinodev.com/arduino-uploader/

1 Like
12

Thank you bperrybap! That is very useful.

The Ardunio Builder tool actually looks kind of like what I want, but, just installing the IDE is probably the same amount of work. And then there is the question of how well they keep that software updated, etc.

Or I could just rewrite the code using the Atmel IDE I suppose.

13

devinw1:
Or I could just rewrite the code using the Atmel IDE I suppose.

How does that solve the problem of field updates?
Seems like all it does is change from one large toolset that must be installed to another.

I would think from a usability point of view the simplest for the end user would be if they had a USBasp device
(they are $2 -$3 on Ebay)
and you provided them with an "update" s/w package that includes the firmware, avrdude, and a wrapper script that when run
updates the firmware in the device.
You end up having create different sub directories for say WIndows, linux, and Mac but once you have done that once,
for subsequent updates, you only have to modify the firmware image in the package.
There can be libUSB driver issues on Windows but you could include those in the Windows specific directory.

--- bill