Reply by dona...@knudsenengineering.com●November 16, 20082008-11-16
Thanks Jeff
Reply by grze...@woodanddouglas.co.uk●November 13, 20082008-11-13
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
Reply by Jeff Brower●November 12, 20082008-11-12
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
Reply by Jeff Brower●November 12, 20082008-11-12
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
Reply by grze...@woodanddouglas.co.uk●October 24, 20082008-10-24
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
Reply by dona...@knudsenengineering.com●October 23, 20082008-10-23
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
Reply by Jeff Brower●October 22, 20082008-10-22
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?
Reply by knud...@yahoo.ca●October 22, 20082008-10-22
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: