Updating firmware from external EEPROM

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Currently, on my ATmega32u4 I am using LUFA Mass Storage bootloader to upload new firmware. While this works great, it's a bit involved, since I have to

 

1) send special message to micro which then resets the board into "firmware update mode"

2) wait until my PC shows a new disk drive

3) replace existing FLASH.bin with new one

4) eject the "drive" to trigger upload process

 

I was thinking of using external SPI/I2C/whatever memory to temporarily store new firmware. Process would then be as following:

 

1) send entire hex file source to micro which would just pass it to external memory

 

After that step, board would automatically reboot, and bootloader would then just copy contents of external memory to micro, resetting the board again once the process is done. External memory would also be cleared to avoid firmware update loop, of course.

 

Is this possible? Has it been done before? I couldn't find anything specific, but then again maybe I haven't looked deep enough.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A perfectly valid technique. With the size of serial flash devices you can keep the previous code as well then roll back if required.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shantea wrote:
Is this possible? Has it been done before?

I've done this very thing using AT45 Datflash. I was using the main part of the storage array for audio data but I reserved some pages up on end to take a received flash image then, given the word, the AVR would run some SPM routines in the bootloader section that read out that image and put it into the AVR application section. One thing to remember is that when the AVR goes into re-programming mode the app section becomes "invisible" (it all appears to be 0xFF) so you cannot have any code involved in the AT45/EEPROM/whatever access in the app section - it must all be "located high" into the bootloader section so it doesn't become invisible (this was very early in my use of AVRs and it took me AGES to work out what was going on!!).

 

In this day and age I think I'd just put an SD/MMC card on there and then use my SD Card bootloader:

 

https://spaces.atmel.com/gf/proj...

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great! Cards are out of the question, it has to be on-chip solution, so I'm looking for best device for my use case, and after some consideration that would be serial flash (eeprom would be slower) with 64kB of memory using I2C. Any model recommendations? SMD only, the smaller the better.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since this is an Atmel site how about:

 

http://www.atmel.com/devices/AT2...

 

Given that Atmel is all but Microchip now how about something from here:

 

http://www.microchip.com/ParamCh...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great, thanks. I'm still actually confused - which file would I need to dump to that EEPROM - hex or bin? Hex seems way larger than actual size of my code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One would think you'd store the binary image in eeprom. How you transport the file is debatable. Intel hex is at least twice as large since each byte is represented by two hex characters. You also have record type, length and checksum information. You really want some form of error checking on the data you send to the micro, so Intel hex would not ge unreasonable, but then there's xmodem, zmodem and countless other means of sending the data.

Last Edited: Tue. Apr 12, 2016 - 12:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I did it I used Xmodem-CRC to get the code from the PC to the AVR as a binary file. To get the binary file in the first place I would likely have used something like:

avr-objcopy -I ihex -O binary proj.hex proj.bin

or just modify the rule that is already producing the .hex in the first place to use "-O binary" instead of "-O ihex" (and to avoid confusion change the name of the output file to be "xxx.bin")

 

To be honest I don't know if even Xmodem-CRC is really necessary to get the .bin data from the PC to the AVR. If you trust the link (like a serial or USB cable) then you can probably arrange to just send the binary data "as is" together (optionally) with some numbers to say how big it is and the address it is ultimately destined for.

 

I'm a great fan of bootloaders that both perform a CRC chceck and check against an embedded value both when the code is first delivered and also each time the AVR then starts up. If you have such a check that further negates the need for the data transmission to be packetized/error checked too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

When I did it I used Xmodem-CRC to get the code from the PC to the AVR as a binary file. To get the binary file in the first place I would likely have used something like:

avr-objcopy -I ihex -O binary proj.hex proj.bin

 

OK, but how to I read the bin file? Hex file is just string of hex values which I can read and transfer to AVR, but how do I do that with .bin?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The same way. There's nothing magic about a bin file. Read X bytes from file, send to AVR. Wait for ack, rinse and repeat.