Automatic in-field Due reflash

Hi Guys,

if you needed to reflash your SAM3X8E while it's sitting in some physically inaccessible place, how would you do it? In our system, we have a Raspberry Pi providing WiFi connectivity to the internet on one side, connected over SPI to the SAM3X8E on the other side.

We want to have a capability to remotely reflash firmware on the SAM. What is the best way to get that done? UART could work but only for one SAM - we may have multiple SAM-based heads in our system.

Any ideas?

thanks,
Valery

Can you specify your needs a little bit more:

  • does "physically inaccessible" mean, that wiring is also impossible?
  • is it possible, to have a hub-kind device, where the SAM3X8E-devices can be cabled to, which itself has another connection
  • How many devices do you expect?

One rough idea could be JTAG:
It is no problem to reflash the DUE with OpenOCD. As JTAG allows chaining devices, it should be possible, to connect several SAM3X8E in a chain, using one JTAG-connector to flash them all.
(http://www.atmel.no/webdoc/avrdragon/avrdragon.section.sqr_osd_lc.html)

I have currently no idea, if openOCD is available for OpenWRT. If yes, there should be a lot of cheap devices out there, which could act as gateway-hub.

Thanks for your thoughts!

This is a product built by us but installed by end user in a remote location. We only have access to it over Internet. The box is sealed for environmental protection.

Hope this helps.

Is programming over SPI possible on SAM3X8E?

Thanks,
Valery

Not SPI, but JTAG:
In the following thread I describe a solution, using an FTDI UM232H board. That small device is a kind of swiss army knife for any kind of serial connections, which you can get for less than $15.0

Using OpenOCD you can use that device for debugging and uploading binary data to the SAM3X8E.

With the configuration described in the linked thread, you can upload code with the following command:

openocd -f interface/FT232H.cfg -f board/DUE-DigiX.cfg -c "program Blink.cpp.elf verify"

What I have not yet tried, is to chain more than one DUE compatible device and access the differently. For that I need to dig little bit more in the OpenOCD settings, but it should be possible, as chaining devices is the most important concept of JTAG.

The Cortex chip is capable of rewriting its own flash memory so I don't see any reason that someone could not construct an SPI based bootloader that can do what is needed. Now, I don't know of any off-the-shelf already done version of this but there should be plenty of examples of bootloaders that could be modified. This would then require zero hardware changes - just the addition of a bootloader located somewhere outside of where the programming must happen. This will probably badly break Arduino compatibility, at least for program uploading, but such is the price you pay.

Thanks Guys!

Collins80 - as long as we can use Arduino to code up the program, then dump the hex file, stream it over the internet to the device, and have it replace the current hex on the device, we'll be fine. Is that possible?

Collin80:
... This would then require zero hardware changes ...

Hello Collin80,

JTAG programming need no hardware changes at all.
You need only an JTAG-interface, which will be connected to the JTAG-pins.

JTAG can be chained, which means, that you need only one interface for the whole chain.

An SPI solution would be similar, however you would need one additional chips select line per device, while JTAG enumerates the devices over the position in the chain.

For both solutions you need the HUB-device, where the slaves (destination devices) are connected to. To make sure, that you can reach those devices from the hub under all circumstances, both solutions will need one additional GPIO per device, to reset in case it is stuck (Similar to the 16u2 solution of the programming port of the due).

The SPI solution needs additional development for the bootloader and programmer, JTAG programming works out of the box.

The SPI solution needs as well development of the client, which interacts with the bootloader. JTAG-access is possible with the gnu-toolchain (gdb, ..) out of the box. OpenOCD runs as server on the hub, and can be accessed over network.

The additional benefit of JTAG is, that it is primarily a debugging interface, which may help during development.

I don't necessarily disagree Gogol. My suggestion was based on my presumption that they already have or plan to have a board where the various processors are connected via SPI. If they're already connected via SPI then why not continue to use that and do firmware updates over the connection as well? If they've already got boards made then using JTAG would require a hardware change and they might not want to do that. Otherwise, you're right, having JTAG would be very handy and bring with it some definite bonuses.

Yes, it is possible to cause the Arduino IDE to emit a permanent hex file that you can grab. Then this file could be streamed over the internet and replace the firmware. Of course, the problem with this approach is that you'd have to write software to do the internet upload and a bootloader that rewrites the firmware. Though, even with JTAG you'd still need some way to stream the firmware over the internet and chances are you'd have to write something for that as well. But, still, the JTAG approach would be a lot less software writing in all likelihood.

The basic outline for SPI based firmware updating would be something like this:

  1. Your control hardware (Raspberry Pi?) sends a command over SPI to the running firmware on a Due/Cortex M3
  2. The firmware sees that this command says to reboot into the bootloader so it shuts down everything and reboots
  3. Upon reboot the bootloader takes control and tells the control side that it is ready
  4. The control side begins to send firmware data which the bootloader uses to overwrite the existing firmware
  5. The control tells the bootloader that it is done
  6. The bootloader jumps to the start of the firmware program

The slight complication here is that you normally want the devices to start up without going into the firmware updating bootloader. On processors with EEPROM the ROM space tends to have a flag set for whether firmware should be updated or not. The Cortex M3 has no EEPROM so you can't signal via a ROM flag. You could store the flag in FLASH memory somewhere outside of the firmware or bootloader space or you could always start up in the firmware updater but timeout quickly if the control side doesn't signal that it is doing an update.

So, it's complicated but possible. I suppose the question is, can you modify the hardware or do you really need to do this via spi?

why so complicated?

I have an wireless interface done with sd+mini pro+bt that does the job over the target's serial port.

Just reverse/see how the update is done on the due by the IDE, then create a small device that performs the update process on the Due.

Jtag is a crazy option.

By default an ARM cortex M3 chip can be reprogrammed by doing a hardware erase and rebooting. This will cause the built-in ROM based bootloader to start. You can then use SAMBA to reprogram the chip over USB serial (and maybe the first serial port as well). So, I suppose it'd be possible to do this in hardware and take advantage of the built-in bootloader. This still requires hardware modification to the boards. JTAG brings with it other nice things that are advantageous when debugging so if a hardware revision is necessary why not use JTAG? With JTAG it'd be possible to put one JTAG header on the board and debug any of the processors.

But, if hardware modification is not acceptable or possible then doing firmware flashing over SPI is perfectly possible and probably the way to go if all the processors are already on the same SPI bus.

Thanks Collin & others for input!

We now narrowed to either native USB or JTAG. Hardware change is ok - this is still in prototype stage.

Collin - would love your feedback on Small-footprint Due - Arduino Due - Arduino Forum

Thanks,
Val

Collin80:
By default an ARM cortex M3 chip can be reprogrammed by doing a hardware erase and rebooting. This will cause the built-in ROM based bootloader to start. You can then use SAMBA to reprogram the chip over USB serial (and maybe the first serial port as well). So, I suppose it'd be possible to do this in hardware and take advantage of the built-in bootloader. This still requires hardware modification to the boards. JTAG brings with it other nice things that are advantageous when debugging so if a hardware revision is necessary why not use JTAG? With JTAG it'd be possible to put one JTAG header on the board and debug any of the processors.

But, if hardware modification is not acceptable or possible then doing firmware flashing over SPI is perfectly possible and probably the way to go if all the processors are already on the same SPI bus.

Again, you don't need any hardware modifications, just a logic analyzer to check protocol, and to connect Due's TX0/RX0 + reset+Erase to an ethernet/wireless enabled arduino mini pro with proper code! The mini pro will handle the update via serial, no complex stuff required here.

He just wants to be able to update the firmware remotely, debugging can be done on prototype that is in the office! :slight_smile:

Just for the record, i checked the Due's schematics and the only pin which is not routed is the "erase_cmd" one, so only one wire would need to be soldered/added/your_preferred_word to this additional hardware for remote flash update. This can be done by hooking directly to the T3 input for 5V, or to the ERASE button output if 3.3V.

BR

BR - thanks for your comments.

However, having to add another MCU board just to reflash the SAM seems like a bit of an overkill. Also, we have six SAMs in our basic configuration system - and up to 20 in the extended config - all need to be reflashed from a central management node (wired). RX / TX approach means buffering lines with Z-state (extra hardware) AND at least one select PIN per device (well, you could add a 5-bit address line but then you need a decoder on every SAM board - more hardware).

So native USB or JTAG are still better IMO. JTAG could be done with just 4 data wires + 2 power. USB - with 3 data + 2 power. Regardless of the number of slave devices. Both JTAG and USB can also be used for bidirectional data transfer, as well, so no additional wiring required..

The only 2 problems I have are:

  1. We are not really familiar with programming over JTAG
  2. I am a bit wary of relying on native USB for everything as there are too much noise I heard on various forums about it being a bit touchy. As we are going to have these devices in the field, I need something relatively rock-solid.

Thoughts?

Val

Bi0H4z4rD:
why so complicated?

I have an wireless interface done with sd+mini pro+bt that does the job over the target's serial port.

Just reverse/see how the update is done on the due by the IDE, then create a small device that performs the update process on the Due.

Jtag is a crazy option.

Hello,

this solutions sounds exactly what im am searching for a long time...would you share some info about it?

I have already running an in-field update of some Pro Minis with an modified RN-41 bluetooth module. But in a new application, i want to do the same with a custom SAM3X8E board (without the U16U2) over the bluetooth serial profile. The problem is, that i have no idea how to integrate some additional soft- or hardware to get the over-the-air-update functional...the bluetooth module itself only support one baud rate, so the switch between 1200bd for starting the bootloader and then switch to the programming baud rate is not possible.

I would be very happy to hear from you or other users to find a solution.

Thanks a lot in advance and best regards,
Stefan