where and how to set the entrance of user's progrom can lead the bootloader go into user's progrom correctly?

[xiaokangkp]

when I refered the AN4258 to make a CAN bootloader(MCU type is MC9S12XEP100), I meet some problems: In the file of StartS12X.s (in bootloader program), it set AppResetVect: equ $effe and use the follow code to enter into user's program: ldx AppResetVect , jmp 0,x ,but when i check the user's program,I cann't find the entrance, where and how to set the entrance of user's progrom can lead the bootloader go into user's progrom correctly? Any help will be appreciated!

[dastek]

Radek wrote :

There is chapter for AN4258:

6 How to write a user application

You must ensure that the user application does not interfere with bootloader area 0xF000-0xFFFF.

1. Create a new project in CodeWarrior Development Studio for Freescale HCS12(X) Microcontrollers.
2. Open the .prm file
3. Trim the segment ROM_C000 from the origianl size 0xC000–0xFEFF to 0xC000–0xEFDF. This is because the area 0xF000–0xFFFF is occupied by the bootloader and the area at address 0xEFE0–0xEFFF will be used for the user application reset vector.

If interrupts are used:

1. Trim the segment ROM_4000 from the original size 0x4000–0x7FFF to 0x4000–0x7F0F. The area 0x7F10–0x7FFF will be used for the relocated interrupt vector table.
2. Create a vector table as shown in the attached demo applications and set the IVBR register accordingly. The IVBR sets the interrupt vector table base address and in this case must be set to 0x7F.

Could you please confirm that you create your application according this procedure?

In default prm file is defined reset vector VECTOR 0 _Startup.

This will generate record in output s19 file like S105FFFEC0003D.

Since address 0xFFFE is already occupied by bootloader reset vector, please erase this line from your application s19 file.

Note: S105FFFEC0003D decoding:

S1 is type of record (16bit address),

05 is size of record in bytes,

FFFE is address of reset vector,

C000 is content of reset vector (start address of your applicaction).

3D is CRC checksum.

When we use ROM_4000 segment (0x4000–0x7FFF) in user application we have to disabling the optimization that changes JSR's into BSR's = the project settings will include the following compiler option: -Onb=b (Go to standard setings (Alt+F7), compiler for HC12, add command line argument -Onb=b (if missing)).

1 of 1 people found this helpful

[xiaokangkp]

Thanks  for your tips.

1- I created my application according<6 How to write a user application>.

2- if  i erase this line(S105FFFEC0003D) from my application s19 file,then i converted  s19 file by SRecCvt tool ,it does not work. 

3-

[RadekS]

Hi Wade, Kang,

Please do not erase reset vector in your application code.

This application reset vector is recognized by bootloader and automatically loaded at address 0xeffe.

Please look at ProgramFlash() code:

      if (ProgSRec.LoadAddr == RESET_VEC_SRC)
      {
        //Program reset vector to address 0xEFFE
        if(Error = PFlash_Program(RESET_VEC_DST, (UINT16 *)&ProgSRec.Data[24]))
          return(Error);
      }‍‍‍‍‍‍

Where reset vector source and destiny are defined as:

#define RESET_VEC_SRC       0x7FFFE0
#define RESET_VEC_DST       0x7FEFF8‍‍

I hope it helps you.

Best regards

Radek

[xiaokangkp]

Hi,Radek
That's very kind of you.

I still don't understand the following problem:

1-What's the relationship between these two addresses:0x7FEFF8 and 0xEFFE?

2-In prm file of the program <S12XEP100 - Demo application - CW50>, i found that : VECTOR 0 _Startup,but I didn't find the relationship with addresses of reset vector which is setted in bootloader :0xEFFE. is there some documents introduced it?

What should I do now?

[RadekS]

Hi Kang,

1) The difference is in memory address format.

The 0xEFFE is Local(Banked) address. Since the page 0xFF is directly allocated in the 64kB memory map (as 0xC000~0xFFFF), we use just the short non-banked address.

The 0x7FEFF8 is Global(Linear) address. This address is used by Flash controller.

In fact, the addresses 0xEFF8 and 0x7FEFF8 point to the same memory byte.

See attached memory map in excel file. Some more details may be found also in AN3784 Understanding the Memory Scheme (targeted rather to older S12XD family).

The RESET_VEC_SRC points to 0x7FFFE0 (0xFFE0 in local address format) because S-Rec file after conversion is formatted to fix 32byte length.

So, when the address in S-Rec line contains this address, we know that the last word (0x7FFFFE~0x7FFFFF) from S-Rec line is Application reset vector.

The RESET_VEC_DST points to 0x7FEFF8 because of the Flash Controller program the P-Flash by 4 words (= 8 bytes = one phrase).

So, the value from address 0x7FFFFE~0x7FFFFF will be placed at 0x7FEFFE~0x7FEFFF.

2) There is no direct technical relationship between reset vector source and destiny addresses.

The reset vector source address is clearly defined by S12(X) hardware. This is default value we do not need to change it in Application project with AN4258 bootloader solution.

The reset vector destiny address may be any address in memory map exclude area occupied by the bootloader. The author AN4258 logically selected the highest address in P-Flash area allocated for Application code (area 0xFF00~0xFFFF is occupied by bootloader). If you want to change this address, please just update RESET_VEC_DST definition and AppResetVect value in StartS12X.s file. This is typically necessary when your bootloader version overgrow default 4kB and you need to allocate more space for it in P-Flash.

I understood your confusion since this great feature is not very well described in the AN4258 text.

You simply do not need to take care of Application reset vector (contains the address where Application starts) until bootloader size is below 4kB. The Application reset vector is automatically moved to the different location by bootloader code.

Note: There is a just small known issue in the bootloader EraseFlash() code when you will use S12XE_256 or S12XE_128 derivatives (case MASK_0M53J and MASK_1M53J_2M53J). The lines

          if(Error = PFlash_EraseBlock(0x7A0000UL))
            return(Error);‍‍‍‍

should be commented/deleted because these derivatives do not contain such Flash block.  

I hope it helps you.

Best regards

Radek

[xiaokangkp]

Hi, Radek

Thanks for your generous help! Now my problem is gone.