search

bitboxelectronics / R2C2_Firmware

R2C2 -- electronics for RepRap 3D printers (and others), CNC and other machines.
http://www.3dprinting-r2c2.com/
35 stars 34 forks source link

Allow firmware update without using SD card #15

Open bobc opened 12 years ago

bobc commented 12 years ago

In some cases the SD card may not be available, or not present. Investigate ways to program the firmware without requiring an SD card.

1) Map the program Flash to a FAT disk, and use MSC. MSC is widely supported and in theory allows a user (or a programming tool). The problem is that the host OS is responsible for allocating the blocks and order of writing. So we can't guarantee that the file blocks will be written in the order and position that the firmware image requires. This method is therefore unreliable between different OS flavors or versions.

We could use raw access via dd or equivalent, but this requires a custom programming tool or script for at least Windows/Linux versions and others.

2) Have a "console" interface in the bootloader using CDC. When in the bootloader, the bootloader accepts commands via USB CDC. A simple protocol allows the host to write to blocks in flash, verify contents etc.

This requires a custom program, but the advantage is that APIs for serial interface are fairly easy to port between platforms. Additonally, the download will work over UART just as well, and could also be used over TCP/IP as a telnet type application.

triffid commented 12 years ago

3) USB DFU - http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard

bobc commented 12 years ago

DFU would be a sensible choice for USB connections.

Perhaps each connection type should use it's appropriate protocol, there are boot protocols for TCP/IP, or maybe just TFTP.

That just leaves UART, perhaps use the manufacturer proprietary one. I don't know if there are any general purpose downloaders, something like avrdude perhaps.

triffid commented 12 years ago

On Sun, Jul 15, 2012 at 7:57 PM, Bob Cousins reply@reply.github.com wrote:

That just leaves UART, perhaps use the manufacturer proprietary one. I don't know if there are any general purpose downloaders, something like avrdude perhaps.

lpc17[56]x has a uart bootloader built in on uart0 that works fine, if a little strangely.. lpc21isp is the tool to use although I have written some of my own utilities to talk to it.

casainho commented 12 years ago

I agree with the problems/difficults of option 1. Current USB MSC bootloader is easy to use for users (but it uses the uSDCard, which we plan to use for now).

I prefer the idea of something agnostic to hardware link, so in future we can use over UART, SPI, Ethernet, WIFI, etc...

bobc commented 12 years ago

If we implement a binary firmware transfer via GCode for the firmware update via SD card, then we could use the same method in the bootloader. It just needs a cut down GCode parser to handle the relevant GCode commands, and instead of writing to the SD card, it could write to the Flash directly instead.

This method would work over USB CDC, UART etc, and the host software could have similar code for SD/direct firmware update.

bobc commented 12 years ago

Oh absolutely, we must preserve the bootloader.

What I was thinking is that if a firmware update fails, then the board will stay in the bootloader after reset. In that case, the user can still access the SD via USB. It would be nice if the host could still write to the SD card via USB CDC, or by a UART if no USB.

But we always have the fall back to USB MSC in case of a failed update, or if the USB CDC update does not work for some reason, so it is perhaps not worth changing the bootloader. It is maybe something to think about if in future we were doing a new bootloader. The current bootloader works very nicely, and a good rule for bootloaders is "if it ain't broke, don' fix it!"

On 17 July 2012 15:37, casainho reply@reply.github.com wrote:

I don't like the idea of being possible to update the bootloader "in a easy" way. A bad programming of the bootloader means a "bricked" R2C2 board.

Reply to this email directly or view it on GitHub: https://github.com/bitboxelectronics/R2C2_Firmware/issues/15#issuecomment-7036951