Linker Autoinit Options

If we take a project that is built with the linker option (-c) and try to bootload with it, it works correctly. If we take the same project, build it with the linker option (-cr) and try to bootload with it, it does not start. Both build versions run fine using the emulator. All critical parameters have been initialized to known values like in the following example:

unsigned parm_name = 10;

We create our boot image using hex55.exe and the following cmd file:

project.out
-i
-serial8
-v5510:2
-reg_config 0x1c00, 0x2C10
-delay 0x100
-image
-o project.hex
-boot
-map project.map

ROMS
{
PAGE 0 : SPIROM : o=0x000000, l=0x015000, fill = 0FFFFh
}

Would anyone be suggest what else we need to be taking into consideration to get the (-cr) option to work correctly from the bootloader? Start a New Thread

Knudsen-

> If we take a project that is built with the linker option (-c) and try to bootload with it, it works correctly. If we
> take the same project, build it with the linker option (-cr) and try to bootload with it, it does not start.
> Both build versions run fine using the emulator.

Why would you expect the -cr option to bootload correctly? That won't work, because -cr disables run-time C code
initialization. The -cr option expects CCS (or a host CPU) to initialize C code variables prior to running the
processor -- which explains your comment "both versions run fine using the emulator".

For bootloading from EEPROM or other external interface (serial port, I2C, etc) it's expected that code was built
using the -c linker option. It doesn't have to be, but again it's not going to work unless the external entity holds
the DSP after loading code, initializes all c variables -- which requires detailed knowledge of the COFF format --
then allows DSP code to run. Why would you want to do that.

-Jeff
> All critical parameters have been initialized to known values like in the
> following example:
>
> unsigned parm_name = 10;
>
> We create our boot image using hex55.exe and the following cmd file:
>
> project.out
> -i
> -serial8
> -v5510:2
> -reg_config 0x1c00, 0x2C10
> -delay 0x100
> -image
> -o project.hex
> -boot
> -map project.map
>
> ROMS
> {
> PAGE 0 : SPIROM : o=0x000000, l=0x015000, fill = 0FFFFh
> }
>
> Would anyone be suggest what else we need to be taking into consideration to get the (-cr) option to work correctly
> from the bootloader? Start a New Thread

Hi Jeff,
Thanks for the quick response. My reading of spra375 and sec. 6.9 of spru281 was that with the cr option data sections (ie, .bss) are copied directly from the boot table into dsp memory by the bootloader (c5509a in this case) without the need for .cinit or initialization code. Still don't fully understand why this doesn't occur - seems preferable to putting .cinit into the memory map. Or why not put the init code into rom as part of the bootloader?

In any case, I really appreciate the help. We'll go with the c option.

Thanks, Don Start a New Thread

Hi

>From spru280H, section 8.19.5 and figure 8-9 seems to –cr option should save some memory, is any way to use this feature when booting from EEPROM?
/Greg Start a New Thread

Donald-

I wanted to get back to you on this...

> Thanks for the quick response. My reading of spra375 and sec.
> 6.9 of spru281 was that with the cr option data sections (ie,
> .bss) are copied directly from the boot table into dsp
> memory by the bootloader (c5509a in this case) without the
> need for .cinit or initialization code.

I don't see how this can happen unless:

a) the external boot device is actually transmitting
COFF format info (in particular, .cinit section
info) to the C5509A bootloader, and

b) the C5509A bootloader actually can parse this
info and understands what to do with it

One way to check is to locate the source code for C5509A bootloader on TI's website,
and go through the code to see if it "knows" anything about .cinit.

The run-time load method (-c option) basically treats .cinit as just another section
that gets loaded, and then autoinit() in DSP/BIOS code takes it from there (or you
can run autoinit separately).

> Still don't fully understand why this doesn't occur - seems
> preferable to putting .cinit into the memory map. Or why not
> put the init code into rom as part of the bootloader?

It's a valid point that handling .cinit at load-time could save some mem. Depending
on the type of ROM you have (connected to EMIF?) then locating .cinit in ROM seems
like a compromise -- avoids using up valuable internal mem or ext SDRAM, but still
initializes at run-time.

> In any case, I really appreciate the help. We'll go with the
> c option.

Ok good luck.

-Jeff Start a New Thread

Greg-

> From spru280H, section 8.19.5 and figure 8-9 seems to -cr option should
> save some memory, is any way to use this feature when booting from EEPROM?

Yes -cr could save some mem. Did you see my other post on this thread to Donald K?
If your EEPROM is on EMIF, then the DSP can read it like any other memory, so you
could locate .cinit there, and yes you should save some int/ext SDRAM/SDRAM mem. But
whether the savings significant is another question -- how big is your .cinit
section?

-Jeff Start a New Thread

Hi Jeff

My .cinit section is (0xC71A - 0xC4C0) in bytes, so not significant at all, but why do not use it if possible.
I saw previous post in this thread, nice to someone notice that before I started playing with that. Only my doubts was about documentation, what could cause misunderstanding and seems not only for me.

Best Regards Start a New Thread

Thanks Jeff Start a New Thread