bootstrap, bootloader and entry point ?

[admond]

hi:

it seems that all others have no question or it is no other than me not to master this platform. I'm just trying to enrich it.

   my first question is: before main(), some function such as startup() called bootstrap or glue code is needed for preparation of main(). sometimes we also need bootloader which does update of users' code. so should I embrace bootsrap into bootloader. I am confused  about both.

 second, although the first and second vectors(both are RESET and COP RESET)  in interrupts vector table are fixed the address of a function, why must entry point of target setting be set as a function and what the result if both of them are referenced to two different functions ?

             sorry for such naive questions.

Best regards

   xidi

[FTSolutions]

I am not certain if I understand your question, but I might be able to help on your first question.

If you have the example stationery/templates in your Codewarrior for the 56F8xxx you can use the bootloader example to create&build a bootloader for your processor that basically matches that which Freescale pre-programs into their chips at the factory.  Program the bootloader into the chip using the JTAG interface.  Then, if you build your application code (in a different CW project) and have the Processor Expert license, you can go to the Processor Expert->Build Options tab and select "Bootloader Support": YES, and put in some number of Bootloader delay seconds value (time in which the bootloader will wait for a potential S-record download to begin).

you can then download your application program into the chip as well..

What this will do:

Chip will begin execution of bootloader code, and will wait for xx seconds (what you specified/downloaded in your application project above) for any program updates to arrive via its serial SCI0 port in Motorol S-record format.   If no S-record arrives, it will look to the topmost 32-bit location in dataflash for the entrypoint address (usually main()) of your application code, and will then launch that application code at that address. 

If you build future application codes to update the previous one in the field, you just have to make the same bootloader support options selected as described above, and provide the S-record file and means of downloading it into the processor through serial port SCI0, and it will update the code, delay time, and app code entry points automatically.

My apologies if I have misunderstood your question - I hope that this is helpful

-Mike

[admond]

yes I partly agreee with you but that: before bootloader jumps to startup routines which is right before main(). this function is responsible for some initialization for main. I checked some datasheet and found this entry point is only useful for linker to dead strip functions and linker doesn't know whether it is interrupt vector address.

[FTSolutions · Accepted solution]

The CW tool will generate the init_asm() code automatically and put this as the entry point prior to main() if you have data which is stored in Program Flash or Data Flash that is to be copied into RAM prior to executing main().  The linker uses the target addresses of the data in RAM, so the assembly language "copy" function must run to copy the block of data from flash (Program or Data flash, as set inthe build options) before main runs - is this what you are referring to?   Are you wanting to change or replace this function?   I think that it might be possible to do this, but I haven't tried to do it myself.

[admond]

Hi Mike:

     thank you for reply so soon.

yes I can't agree with you more. the init before main does some data copies as well as stack setup and so on. it is produced by compile and should stay intact. as to the interrupt vector table, when you change the vector base address in fact the first addresses for RESET is none used, i think. the real reset vector addresses are located in bootloader section. any opinion , please share. thank you

     xidi

  05.09.2009

[FTSolutions]

The very first vector in the table is for the RESET interrupt, the second vector in the table is for the COPReset int.   Depending on your design, the RESET interrupt may end up forcing your hardware to perform a hard reset and begin executing from the bootloader again anyway.  

I believe that you can change the CPU vector table address to what you wish by doing:

/* interrupt vector base address change to Program Space P:0x?0000 */

/* memory locations/addresses are processor specific                        */

/* on 56F8367 INTC_VBA  *((volatile word 8) 0x0000F1AA)              */

/* my_vector_addr can be created by you, or if default generation by */

/* CW toolset it is _vector_addr at start of interrup_vectors section defined in */

/* the project's linker   .CMD file  and the default Reset vector is the address */

/* of _EntryPoint (which is the CW tool-generated initialization routine called */

/* before main()   */

NewInterruptVectorTable = (UInt32)&my_vector_addr;

setReg(INTC_VBA, (NewInterruptVectorTable>>8));

If you have the stationery templates and example codes installed you can look at a bootloader example project for more on how the interrupt vector tables can be adjusted.   Note that the Vector Base Address register code above assumes the vector table is aligned on memory space boundard with lower8 address bits = 0.

When my bootloader code has loaded a new application program code, the application flash is mapped to address 0x00000000.  So, my vector table for the application code  is at this address.  After the bootloader finishes its thing it changes the vector base address from its table in boot flash space to the address in program flash space using the code above, but using my_vector_addr= 0x0000000 as described.

Hope that this is helpful.

[admond]

thank you for response.

Yes, that is the case going to be. meanwhile, I want your view on the reset vectors (both reset and cop reset): even you change the base address for vector table, for example changed to 0x00 0000, it does't necessarily mean reset vectors changed, in fact the first two entrence of the new vector table are no used and the really addresses for reset are unchangable in bootloader. is that right?

    Xidi

05.11.2009

[FTSolutions]

OK, I believe I understand your question - the answer is yes, the Reset and COP Reset vectors will still be pointing to bootflash - UNLESS you are operating the device in EMI_MODE=0, MA bit=1, but then you are also not using the internal boot flash for bootup.  These first (2) vectors must contain either a JMP or BRANCH instruction and in most of the memory interface operating modes these will by default point back to bootflash location.  As I am using 56F8367 this maps to memory address locations 0x40000 and 0x40002 for RESET vector and COP RESET vector, respectively.

If you are operating the device in the EMI configuration identified above with an external boot flash device you could change  these vectors but basically the only thing that you could change them to be in this mode would be 0x00000 and 0x00002 to map into your external boot memory.

I am sorry for not understanding your query earlier.   Your understanding of the RESET and COP Reset vectors is correct, I believe - at least I am of the same opinion.  So if wrong, we are both wrong!

[admond]

Hi:

   thank your for you excellent answer. I agree complete.

   by the way, I have a doubt which I do not want to open a new one for delivered too many tips in the forum. I used may USB tap, download is OK, but I am not satisfied with the speed when step into. it takes about 2 seconds to complete. what do you think of this , is this normal? for usually I used REAL ICE from MICROCHIP, step into with mplab is quite soon. before 1 second achieved, 4 or 5 second should be took. after I modified 500 to 1500 on JTAG CLOCK SPEED. I can't connect the target with USB tap at more than 2000 of JTAG CLOCK SPEED. so I also like to know what the maximum of JTAG CLOCK SPEED in specificaton.

   Xidi

[FTSolutions]

I use both a parallel port (Macraigor Wiggler) and also USBTAP and I think that one is supposed to actually run the clock settings at the same speed (500) according to some documentation that I recall seeing in Freescale documentation, but cannot locate right now.  However, I find that I can run USBTAP at up to 1500 (but not above this) reliably.  So this matches your observation.  I usually run with USBTAP setting at 1000.  The USBTAP at 1000 or 1500 can download large code projects more quickly, but stepping into functions is not significantly faster than with the Wiggler.  So, I have the same observations as you have - it seems to be slower stepping into functions than other ICE/debugging tools I've used on other processors - I think it must relate to the driver software in CW.  This appears to be 'normal' for this software, but at least one can set many many breakpoints in CW where you are much more limited in MPLAB.

[admond]

yes You really read my mind. I have the same view as you have. If I get any problem, hope to share your view. thank you.

Xidi

05.15.2009