Bootloader for S12

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bootloader for S12

Jump to solution
3,405 Views
cs_Lukasz
Contributor III

Hello!

 

I have once more question about bootloader for 9S12 (I.m using XEP100). I was succesfuly implemented LRAE and LFAE bootloader. But it is disposable ;/. I have to remake it that it can be used repeatedly. I'm not sure am I doing this in good way. In application which is loading to flash I change in *.prm file reset vector from VECTOR 0 _Startup   to    VECTOR 0 0x4000. So processor must always jump to bootloader after reset and just then jump to my app (addr 0xC000). Question is how to prepare flash pages to load new flash. And is it good solution to change reset vector is my app to bootloader start vector? Maybe have anybody FW example with these bootloader?

Labels (1)
0 Kudos
1 Solution
720 Views
kef
Specialist I

Subject is long to explain and I don't know what AN to suggest. But traditional (and IMO the best) concept of bootloader is this:

 

Bootloader along with bootloader vectors resides close to vectors area at 0xFFxx.

 

Bootloader and bootloaders vectors are write protected. (additional security, what if program update doesn't complete and power disappears/ reset happens etc). Write protection is done programming NVPROT location.

 

On reset, bootloader is started first. Bootloader verifies complettnes of application uploading process, or maybe checks application checksums.

    If passed, then bootloader changes IVBR register setting to move vectors base address to where application vectors are expected. Application vectors probably should be just below bootloaders write protected area. And finally bootloader jumps to the contents of application reset vector address.

    If application upload was not complete, or checksum doesn't match, then bootloader should awaiting for communication requests from CAN / SCI etc

 

For security reasons I recommend your bootloader should not autoerase application flash when application check doesn't pass. What if somewhat failed and bootloader didn't jump to application and is going to erase application...

 

Application and bootloader should be two separate applications.  

 

Application should recognize some commands from communication channels, or maybe have dedicated pins to command jumping from application to bootloader. How you do it is up to you. Hovewer the recommended jump back to bootloader should be done using internal resets, maybe COP, maybe illegal address reset or any other. How bootloader will recognize which reset is normal reset and which was requested by application is again up to you.

 

 

In PRM reset vector should still point to _Startup, but vector should be moved to below bootloader write protected area.

 

VECTOR (0+ <bootloader size> / 2) _Startup

 

 

and for all other vectors:

 

VECTOR (X+ <bootloader size> / 2) vectorXaddress

 

 

Bootloader size divider by 2, because vector occupies 2 bytes. '+' sign because least vector occupies highest address.

 

Hope this helps

View solution in original post

0 Kudos
2 Replies
721 Views
kef
Specialist I

Subject is long to explain and I don't know what AN to suggest. But traditional (and IMO the best) concept of bootloader is this:

 

Bootloader along with bootloader vectors resides close to vectors area at 0xFFxx.

 

Bootloader and bootloaders vectors are write protected. (additional security, what if program update doesn't complete and power disappears/ reset happens etc). Write protection is done programming NVPROT location.

 

On reset, bootloader is started first. Bootloader verifies complettnes of application uploading process, or maybe checks application checksums.

    If passed, then bootloader changes IVBR register setting to move vectors base address to where application vectors are expected. Application vectors probably should be just below bootloaders write protected area. And finally bootloader jumps to the contents of application reset vector address.

    If application upload was not complete, or checksum doesn't match, then bootloader should awaiting for communication requests from CAN / SCI etc

 

For security reasons I recommend your bootloader should not autoerase application flash when application check doesn't pass. What if somewhat failed and bootloader didn't jump to application and is going to erase application...

 

Application and bootloader should be two separate applications.  

 

Application should recognize some commands from communication channels, or maybe have dedicated pins to command jumping from application to bootloader. How you do it is up to you. Hovewer the recommended jump back to bootloader should be done using internal resets, maybe COP, maybe illegal address reset or any other. How bootloader will recognize which reset is normal reset and which was requested by application is again up to you.

 

 

In PRM reset vector should still point to _Startup, but vector should be moved to below bootloader write protected area.

 

VECTOR (0+ <bootloader size> / 2) _Startup

 

 

and for all other vectors:

 

VECTOR (X+ <bootloader size> / 2) vectorXaddress

 

 

Bootloader size divider by 2, because vector occupies 2 bytes. '+' sign because least vector occupies highest address.

 

Hope this helps

0 Kudos
720 Views
wilero17
Contributor I

Hi I'm working with the bootloader. Actually I'm needing to do a Reset once the user program has been uploaded. I'm using the watchdogtimer but I've configurated the COPCTL register with 71

(COPCTL=71) the program stay in a infinite for loop showing a caracter ascii in the hyperterminal until the watchdog finish. The problem is:  after the watchdog timer has finished the program doesn't reset o may be yes, but I can't see more caracters in the hyperterminal until I do a manual reset. 

 

this is part of the program:


 

COPCTL=71;ARMCOP=0x47;for(;;) {}

 

 

I hope that you can help me. Many thanks

 

 

0 Kudos