c6701 bootload

Si Cheng,

A bootloader will usually initialize the system enough to write to all required memory at the best speed and then branch to the starting point. The starting point is usually _c_int00, and after that point is when the C environment gets initialized, including the stack.

So there is no need to save/restore those registers, unless you are doing something much different than a simple bootloader.

Regards,
RandyP

RandyP:

I do crc32, flash erase and write in my bootloader, Need I save/restore those registers??????

Thanks!

Si Cheng,

What values would be in those registers before your bootloader starts running? Did they have valid or required values prior to the bootloader running?

Do your functions require these values to be restored for these functions to work properly?

What happens at the end of your bootloader that is different from what I described above?

In what language are these functions written, C or assembly?

Regards,
RandyP

RandyP:

 these functions are written with assembly, in the bootload.asm, before copy the data from flash, I will do crc32, flash erase and flash write , and then copy the data and jump to _cint00. I will not use those registers in the bootloader . 

thanks!

Si Cheng,

When you jump to _c_int00, the assumption is that the physical resources like EMIF and PLLs are initialized, but nothing for the actual code. It is assumed this is immediately after power on.

Does the C Compiler User's Guide mention anything about requirements going into _c_int00?

Regards,
RandyP

For the c6xxx using the standard CCS tools, _c_int00 itself assumes nothing, and sets up the stack pointer (B15) and near-data pointer (B14), copies initial data values from the "cinit table" if any, and executes static constructors before calling the main() function.  For a RAM-based build, normally _c_int00 is executed directly from the RESET vector or is used as the starting location ("entry point") under JTAG control.  This means that the EMIF has *not* been set up, for example with external SDRAM access parameters.  When started from CCS via a JTAG emulation, normally a .GEL file is executed first, to set up EMIF and other necessary environmental parameters.  If the code is to be booted from ROM, then the "secondary bootstrap" (typically 1KB that were copied from CE1 space starting at relative address 0 to internal SRAM starting at absolute address 0) needs to do more than _c_int00 normally does, including setting up the EMIF and copying much of the application from its load area in ROM to its run-time addresses in RAM.  Note that the bootstrap must not assume that the stack or near-data pointers are already set up; if it uses them it must first set them up itself.  The bootstrap can end by branching to _c_int00 to do the data initialization and execute static constructors and call main().  There are a few TI documents concerning ROM booting, but I didn't find any of them to be exactly on the mark.  (Once I work it out for my own application, I'll probably write up what I did.)