Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Attempt to write Bootloader for flash-update via LAN

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive
View previous topic :: View next topic  
Author Message
Arera

Bascom Member



Joined: 23 Sep 2007
Posts: 375
Location: Wuppertal, Germany

germany.gif
PostPosted: Sun Oct 27, 2013 2:21 pm    Post subject: Attempt to write Bootloader for flash-update via LAN Reply with quote

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 )
Back to top
View user's profile
six1

Bascom Expert



Joined: 27 Feb 2009
Posts: 552

germany.gif
PostPosted: Sun Oct 27, 2013 2:47 pm    Post subject: Reply with quote

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

_________________
For technical reasons, the signature is on the back of this message.
Back to top
View user's profile
Arera

Bascom Member



Joined: 23 Sep 2007
Posts: 375
Location: Wuppertal, Germany

germany.gif
PostPosted: Sun Oct 27, 2013 3:27 pm    Post subject: Reply with quote

Hi Michael,

good idea, I've had it too, if you carefully read my lines...
Wink
Back to top
View user's profile
six1

Bascom Expert



Joined: 27 Feb 2009
Posts: 552

germany.gif
PostPosted: Sun Oct 27, 2013 7:33 pm    Post subject: Reply with quote

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

_________________
For technical reasons, the signature is on the back of this message.
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5070
Location: Holland

blank.gif
PostPosted: Sun Oct 27, 2013 11:11 pm    Post subject: Reply with quote

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 :

Code:
#if Loaderchip = 88                                         'Mega88
    $loader = $c00                                          'this address you can find in the datasheet
    'the loader address is the same as the boot vector address
    Const Maxwordbit = 5
    Const Maxpages = 96 - 1                                 ' total WORD pages  available for program
    Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
#endif

.....

          If Page < Maxpages Then                           'only if we are not erasing the bootspace
             Page = Page + 1                                   'next page
             Spmcrval = 3 : Gosub Do_spm                    ' erase  next page
             Spmcrval = 17 : Gosub Do_spm                   ' re-enable page
          Else
             Portd.7 = 0 : Waitms 200
          End If
 


To use TCPIP i would use http GET to get new firmware. The last 4 bytes should/could include a crc32.

_________________
Mark
Back to top
View user's profile Visit poster's website
Arera

Bascom Member



Joined: 23 Sep 2007
Posts: 375
Location: Wuppertal, Germany

germany.gif
PostPosted: Wed Nov 13, 2013 9:58 pm    Post subject: Reply with quote

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 IC).

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!
Back to top
View user's profile
amirf

Bascom Member



Joined: 25 Aug 2009
Posts: 154

indonesia.gif
PostPosted: Thu Nov 14, 2013 1:09 am    Post subject: Reply with quote

it would be nice if you share your success story in Application note (AN) Smile
Back to top
View user's profile
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum