RE: RE: 5213 bootloader

Hi Wendi,
 
I would like to use the bootloader to flash new applications only when a firmware upgrade has been created. This will allow the customer to perform firmware upgrades in the field.
Also I had intended to perform a checksum operation during the flashing of the new application.
 
Pat

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Wendi Whitcomb
Sent: Tuesday, January 29, 2008 12:11 PM
To: Patrick Flannery
Subject: RE: [ColdFire] RE: 5213 bootloader



Hi Pat:

 

I think I read in your previous email that you must comply with some sort of regulatory agency as well.  If this is true you will most likely need to insure the code is good in some way (i.e checksum).  This should be run by the "bootloader".  Additionally I would like to clarify on how you want to run this "bootloader".  Do you want to always load the app or sometimes want to Flash the new code with the bootloader?

 

Wendi

 

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Mark Butcher
Sent: Tuesday, January 29, 2008 3:19 AM
To: wrw
Subject: AW: [ColdFire] RE: 5213 bootloader

 

Hi Pat

 

If you are using a serial interface for loading new code there is no reason for keeping the old code also in FLASH (this is only useful if SW uploads are remote - via Internet for example - where a failure could otherwise leave the device in a state which inhibits further communication).

A boot loader via serial interface will require about 4..6k of space so you will have no problems with your application size.

 

The boot loader is independent of the OS used. It must simply ensure that the new code is loaded to the correct location (this is defined in the SREC) and then passes control to it (it needs to be able to jump to the start address of the new code - which can be a fixed address for simplicity - eg. start of first unused FLASH sector after the boot code). The application will need to have its interrupt vectors in SRAM (which is probably the case with MQX-Lite anyway) because the boot code must have its vector table fixed in FLASH starting at 0x00000000 so that it can handle the reset. VBR is set by the application to where its own interrupt vectors are stored.

 

Regards

 

Mark

 

 

 

Mark Butcher Bsc (Hons) MPhil MIEE

 

M.J.Butcher Consulting                

Obere Bahnhofstr. 13,  CH-5507 Mellingen,

Switzerland         www.mjbc.ch <http://www.mjbc.ch/>  / www.uTasker.com <http://www.utasker.com/> 

056 491 48 10 / 079 402 26 37 / Skype: M_J_Butcher

<http://www.uTasker.com>  

 

 

-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] Im Auftrag von Patrick Flannery
Gesendet: Dienstag, 29. Januar 2008 00:31
An: [email protected]
Betreff: [ColdFire] RE: 5213 bootloader

 

Wendi, Mark, Steve,

 

Thank you all for your timely responses. 

 

I didn't think that the RTOS that the application is using made a difference to a bootloader program so I didn't mention it in my original email. We are using a MQX RTOS for the MCF5213 known as MQX-lite. Is the RTOS that the application is using important? I thought once it was compiled it became part of the S19 file produced by the Code Warrior compiler. The bootloader I had envisioned would receive the S19 file a sector at a time thru the serial port, store it in SRAM, and then flash it into the 5213 flash. Am I oversimplifying what's required?

 

1. the bootloader reads a minimum flash sector size (2k) of the new application into SRAM through the serial port;

2. it flashes that into the next sector of the 5213 flash. 

3. steps 1 and 2 are repeated until the new application has been fully received and flashed.

 

The 5213 flash is 256k and my application is above 220k so there isn't room to keep a copy of the old application stored anywhere in case the flash of the new application is unsuccessful. Since the hardware design is fixed and can't be changed, adding an external memory isn't possible. I realize this isn't the optimum method but I inherited the design and it's fixed due to safety approvals required by the application.

 

Pat

 

 

[email protected] Send a post to the list. [email protected] Join the list. [email protected] Join the list in digest mode. [email protected] Leave the list. [email protected] Send a post to the list. [email protected] Join the list. [email protected] Join the list in digest mode. [email protected] Leave the list. [email protected] Send a post to the list. [email protected] Join the list. [email protected] Join the list in digest mode. [email protected] Leave the list.