Reply by Steve Russell January 1, 20052005-01-01
Baljit,

This is my understanding of the terms, and a short tutorial on the functions.

I hope that its not quite more than you wanted to know.

I trust that others will note inaccuracies and differences in their
understanding of the terms.

"Startup Code" is a generic name for code that runs when the system starts
up, typically after power on.

A "Bootstrap Loader" is a particular kind of startup code that runs when a
system starts up, that will reprogram the application code in flash memory
if asked.

In automotive systems, a "bootstrap loader" is common, because the HC-12 is
sealed in a box, and it is much less expensive for the dealer to plug into
a network somewhere in the car and reprogram one the mob of computers in
the car than it is to have to get the offending box and plug into
it. Because of this and security requirements, these bootstrap loaders may
be rather elaborate.

(The term "bootstrap" has long usage with computers. It comes from the
idea that a minimal loader can load a much larger and useful program into
memory in a process similar to "lifting oneself by one's bootstraps".)

On the HC12, "startup code" often refers to assembler code that does things
to make it possible for a compiled C program to run.

Sometimes "initialization code" is used in contrast to refer to C code that
sets up IO devices and system variables. This code runs after the
assembler code has prepared the CPU to run C code. Required Tasks for HC-12 "startup code"
--------------------------------

Write the INITRM register so that it is defined, and its "write-once"
property is activated. This fixes the location of RAM in memory.

Set the stack pointer (SP) register so that the CALL, JSR, PUSH and POP
instructions will work as expected. Typical Additional Tasks for "startup code"
-------

(These may be written in C once the RAM location is fixed and the stack
pointer are set.)

Write the INITRG register so that the register block has a fixed location.

Write the MISC register so that the flash window from 0x4000 to 0x7FFF is
defined as flash, or not.

Write the INITEE register so that the EEPROM has a fixed location.

Write the COPCTL register to make sure that the COP watchdog timer is
running for normal operation, or not running for debugging.

Note that the above functions need to have matching provisions in the
linker directive file so that the application code is linked with the
proper addresses. This is a frequent source of problems when starting to
debug a new application. Bootstrap Loaders
-----------------

There has been a lot of discussion with "bootloader" or "bootstrap loaders"
in this list. A recent long discussion had the subject "HC12 flash
reliability" because a question about flash reliability turned out to be
raised by the behavior of a particular bootstrap loader. If you want to
know more about bootstrap loaders, look in the mailing list archives for
these subjects.

Unfortunately, the automotive bootstrap loaders seem never to be discussed.

Hope this helps,
Steve Russell
Nohau Emulators

At 09:14 AM 12/31/2004, B singh <> wrote:

>Hi, there
>
>What is the difference between Startup code and
>Bootloader?
>
>If any body can hellp
>
>thanks
>Baljit >
>__________________________________ >
>
>Yahoo! Groups Links >
>




Reply by B singh December 31, 20042004-12-31
Hi, there

What is the difference between Startup code and
Bootloader?

If any body can hellp

thanks
Baljit
__________________________________




Reply by James M. Knox December 31, 20042004-12-31
At 09:14 12/31/2004 -0800, you wrote:

>What is the difference between Startup code and
>Bootloader?

I guess it depends in part on your definition of "startup code." In this
case the device needs the ability to load new (updated) versions of both
operational software and data tables in the field (i.e. without a BDM
pod). Simplest way to do that, since we needed RS-232 capability anyway,
was to put some software in one of the protected banks of flash. This
software would then be capable of reading a file from the RS-232 port and
loading it into Flash.

Part of the trick is, how do you invoke it? One way is to use a dedicated
discrete input pin and use a "jumpered" plug - but we didn't have any that
come out to the RS-232 port. Besides, it would still require STE, namely
the jumpered plug.

So we went with the following:

o Upon power initiation control is always transferred to the boot loader
which initializes the processor and performs a CRC on the operational and
data areas of Flash.

o If the CRC fails then the bootloader code clears Flash and waits for a
new download. [This path is for when the Flash is trashed, or has never
had the program loaded.]

o If the CRC passes, then the bootloader waits a few seconds for a special
"handshake" signal over the RS-232.

o If it gets the handshake, it loads in a new program; else it simply jumps
to the operational code which re-initializes the processor as it wishes and
starts running.

As has been pointed out, and in hindsight, it would have been better if the
bootloader did not clear flash, but rather (if a new program was needed)
simply waited for the handshake. Also, it probably would be safest if it
were a bootstrap loader rather than the bootloader itself (i.e. it loaded
the bootloader program).

jmk -----------
James M. Knox
TriSoft ph 512-385-0316
1109-A Shady Lane fax 512-366-4331
Austin, Tx 78721
-----------