The team at Wicked Device has been working on working on a way to upload Arduino sketches over Ethernet for the Nanode and Arduino Ethernet boards. The team has gotten far enough along to show the world, and the new boot loader shows a lot of promise.
A new boot loader was needed to perform this magic. The boot loader sets up a TFTP with a server over DHCP or a static IP. An unmodified .hex file is downloaded from the server and the sketch starts up. The team is still working on a way to push new apps to the board over Ethernet, but that feature is expected to be completed sometime soon.
Booting over Ethernet isn’t a new idea – TFTP was proposed for this very purpose. Because Wicked Device’s Ethernet-enabled boot loader only works over a local connection and requires a press of the reset button, it should be considered an alpha build. That being said, the boot loader works as advertised, so check out the demo video after the break.
[vimeo=http://vimeo.com/28909414]
TFTP client and raw HEX files – that’s great!
I could imagine that the AVR will load the HEX file from the server every time it’s powered on so the chip has always the most actual firmware.
Not a new thing for microcontrollers either- Microchip has had one in their (not quite “free” but royalty free source code available via a click-through license) TCP/IP stack (since 2009 at least, possibly earlier).Their bootloader is only for the PIC18. There are also non-free bootloaders for the other products in the Microchip TCP/IP portfolio (such as those at Brush Electronics).Doing a bootloader over TCP/IP is pretty hard as you need quite a bit of code just to run TCP/IP (and typically you don’t reuse bootloader code in your main application).NB: I may be biased toward Microchip, but my opinions are my own
As you said, the bulk of the code would be for the NIC driver and TCP/IP stack, but this could easily reused by the main application if the bootloader code was properly designed. Chances are if your booting over TCP/IP you’ll need a stack in your main application as well.
I understand that the functions are shared, but if you need to update the main TCP/IP stack, if you share that code with the bootloader, you’re SOL. Bootloader code I’ve seen at the microcontroller level is usually separate from the main stack. I have not looked at this code in particular, but TFTP is often implemented with just UDP, and allows you to make a smaller working subset of the stack exclusive to the bootloader.If you keep the bootloader code simple, separate, and well tested, if the main code has a problem, you can fall back to the bootloader to update the code- if you share the code and have a bad bootload, you’ve bricked your device. Keeping the stacks separate is not the only way, but safer and the way I prefer to code.
Interesting… I’ve been thinking about writing a bootloader for the tiny2313 for flashing over RS485. Flashing would take place on a network of multiple devices, so I could attempt to program them simultaneously, or just flash one device on the network at a time.
It is very cool that Hack-a-Day picked up our video! Thanks. I just wanted to take a quick second to update and clarify a couple of the finer points in this post.
1. What is downloaded via TFTP is not actually the hex file, but a binary image that I “compile” from the hex file (sounds harder than it actually is to do).
2. The bootloader does not have DHCP, it requires static IP parameters, but the parameters are modifiable and stored in EEPROM. There’s only so much flash for the bootloader, and I had to make this compromise to make it fit. I don’t think this is really a severe limitation though.
3. Since the video came out, we actually have achieved a download over the internet (i.e. not just on a LAN) which I found really exciting personally!
Keep an eye on this as we are working hard to make it “real” – Cheers, Vic
Just wanted to thank the Nanode guys for all the hard work they have donated to the community! This is an excellent feature for any networked product. I am a design Engineer for a NetBurner Inc. but still like play around with Arduinos and other modules in the “maker” market. Compared to the Arduino we produce somewhat higher-end embedded Ethernet modules for the Industrial market ( 150MIPS, 8MB RAM, 90+mbit network throughput, Industrial temp, 1 Watt ) as well as the software tools to develop end applications for our hardware. Our software has supported application updates via Ethernet for over 10 years. We support TFTP updates in the boot monitor. The end application code provides functions for network updates via UDP, TCP, FTP, HTTP, Email… ext. Now that I am used to the network updating speed, serial port updating has become so painfully slow.
The update code in the majority of our products is not too complex, extreamly robust and takes about 1 second to complete an update. The robustness is mainly due to the fact that we have 8MB of RAM and 2MB of FLASH. About a year ago we released a low cost module with 32K RAM/256K FLASH and the network update procedure was much more challenging to implement. The FLASH must be written at the same time the application is being downloaded since there is not enough space to store it all in RAM. A good amount of RAM is already being used up for network buffers, especially with TCP since you must hold onto data until ACKed. TFTP only uses UDP which makes it an obvious initial step when developing network updating on ram limited embedded systems. When the application size is larger than the available RAM, it is not possible to perform a full integrity check of the new application before writing it to flash. While we have developed ways to better ensure the app is valid there are still many more possible failure modes during update… ie. loss of network connection mid-update. The Nanode developers are likely battling these same troubles.
Another neat network development feature we support is the Eclipse based GNU GDB debugger running over Ethernet. This was a much greater challenge then the software update functionality. It still blows my mind that it is possible debug and step through the network stack of an embedded module via the same network interface… on the other side of the world.