RE: RE: 5213 bootloader

"Wendi Whitcomb" <[email protected]>
Newsgroups gmane.comp.hardware.motorola.microcontrollers.coldfire
Message-ID <019501c86299$f31e59b0$14ffa8c0@WRWZOZO4>
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          <http://www.mjbc.ch/> www.mjbc.ch /
<http://www.utasker.com/> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.