Attempt to write Bootloader for flash-update via LAN

Arera · Joined: 23 Sep 2007 Posts: 386 Location: Wuppertal, Germany

Hi folks!

I'm using the WIZ820IO LAN module with great success.
And I use the MCS bootloader via UART with great success.
My new attempt is to build a bootloader, that works via LAN.
The idea (not mine, I've got it from this forum) is:

1- connect an external I2C EEPROM to the micro (mega1284p).
2- send the .hex-file via LAN and store the data into the external EEPROM.
3- the BL gets data from the EEPROM instead from of the UART.

While adapting the MCS-BL routine, a question occured:

Each page that is written into the flash, must be erased and re-enbled first.
This is how the MCS-BL does it:
- fist of all erase and re-enable page 0 at the start of the bootloader
- start a "for next to 128" to write 128 bytes into the page.
Inside, at the end, of this loop, the next page is prepared to write to by erasing and re-enbleling it.

My question:
Imagine my application is exactly as big as the remaining flash size (flashsize minus booltloader-size).
Then, after writing the last page, the NEXT PAGE after the last page is erased.
This kills the bootlader.

I'm going to bootload every flashbyte up to the BL-section, regardless of the actual hex-file size (unused bytes will be filled with &HFF),
that's why this really matters to me.

IMO it was more logical to prepare EACH (including the very first) page inside the flash-writing-loop, just before writing to the flash).

The "MCS-way" seems a bit odd to me, on the other hand Mark and many others have a far deeper understanding of all that stuff,
that's why I feel a bit unsure about this.

Any ideas and hints are welcome!

Marc

(BASCOM-AVR version : 2.0.7.7 , Latest : 2.0.7.6 )

six1 · Joined: 27 Feb 2009 Posts: 553

Hi,
think it is not the best idea to flash it on the fly...
I do it by using a external serial eeprom (ESF) from Atmel (AT45DB041D-SU) with great success Laughing

Load whole new System into ESF in your Main Programm. If the Checksum is ok, set a Flag inside a Codepage from ESF.
Modify Bootloader to check ESF Flag and if it is set, flash the System out of the ESF.

best, michael

Arera · Joined: 23 Sep 2007 Posts: 386 Location: Wuppertal, Germany

Hi Michael,

good idea, I've had it too, if you carefully read my lines...
Wink

six1 · Joined: 27 Feb 2009 Posts: 553

AREA send an email to michael [at] koecher-web [dot] de
will send you the ESF DUAL-Bootloader (serial and ESF)...

albertsm · Joined: 09 Apr 2004 Posts: 6200 Location: Holland

Do not forget that the included SAMPLES are just simple samples. They are kept simple as possible deliberately. The idea is that the users extend/change them.
The best practice for a bootloader is indeed to store the new loader local in some chip/flash card, and then perform a check sum. When all is ok, set some flag (a shared EEPROM location that stores a byte indicating that a new program must be loaded) and then reset the chip (preferably using a time out of the WD).
Then in the boot loader, check the EEPROM flag and simply copy the code and when done, test the memory and when done, reset the FLAG and reset the chip.
You could also include some simple backup of the firmware that is copied when everything else fails.

the bootloader sample erases the page but in a real product you should include a check : in the EDB bootloader (for M88) this is done like this :

Arera · Joined: 23 Sep 2007 Posts: 386 Location: Wuppertal, Germany

I've got the network bootloader working!

Thanks SIX1 for sharing your code, but I found that the whole task depends a lot from the HW and the rest of the project.
Different ext. EEPROM use differend ways to be read or to be written, for example.

I use a 24AA1025 (128Kx8 I²C).

The most tricky part for me was to create a PC software to transfer the .hex file. So I asked a friend to write it and he did!

My project is hughe and I cannot just copy the update parts to show you.
But I can encourage everyone to try it!

First find a way to get the Firmware into the ext.EEPROM. I send the hex-file line after line. Each line contains a checksum, very easy to check, see wikipedia "Intel Hex". I even check the address contained in each line to gain safety. After I send an "ACK" to the PC, the next line will be send.

The MSC bootloader sample appears less mystical after removing all the serial communication stuff.
Then I added "DIM bl_rqst as ERAM byte at &Hxx", both in the main application and the bootloader.
After loading the new hex-file into the ext. 1Mbit EEPROM and doing some checksum stuff, I write a 1 into that ERAM-var, and "reboot" the chip.
The BL starts and sees the "1". Now the bootloader copies the EEPROM content into the flash, resets the BL_rqst and resets the micro.

BTW, after getting this working, I re-added the MSC serial BL part and got an dual-bootloader.

One more hint: The intel-hex format offeres functional lines, setting the address-pointer and setting the block-number of 64KB-blocks.
Some hexfiles contain a first line, saying "Address = 0; Block = 0". This sets the main application reliably to the right values, even if the last transfer was aborted. Most hexfiles miss that line, so my PC-soft generates it at the beginnng of the transfer.

This is my (tested) idea of a network bootloader, the rest is up to you.

Thanks to all for getting me on the right track!

amirf · Joined: 25 Aug 2009 Posts: 154

it would be nice if you share your success story in Application note (AN) Smile