Reply by Jeff Brower February 8, 20082008-02-08
Xiyu Shi-

> You assessment about the initialization of SDRAM at the entry point is
> right. The EMIF registers should be properly set up before anything is
> run if use the SDRAM.
>
> I'll need to understand more about the .cinit and the initialization of
> EMIF for SDRAM.

Ok... sounds like something to try. I suggest to put in some small asm lang code at
the _cint00 entry-point. Let this code run, then jump to DSP/BIOS entry-point.

You can also look at the "User Init" function option in DSP/BIOS setup. However,
this function still runs after auto_init (.cinit initialization). You might be able
to get it to work if you don't call any CSL or BIOS functions and don't declare
anything any static or const. But even in that case, in our previous experience, we
found the User Init function to be inconsistent among BIOS releases and different DSP
devices. Also in my opinion it doesn't "self document" the project like _cint00
code. Placing some boot-code at the _cint00 entry point clearly documents the need
to do something critically important *before* anything else in the system runs.

-Jeff

> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: 07 February 2008 22:00
> To: Shi X Dr (Electronic Eng)
> Cc: c...
> Subject: Re: [c55x] C5510 Application doesn't work after FlashBurn with
> .cinit allocated in SDRAM
>
> Xiyu Shi-
>
> > I am using a Spectrum Digital TMS320VC5510 DSK board to develop an
> > application. The application, after FlashBurn to the onboard FlashROM,
> > runs OK if I allocate the Data Initialization Section (.cinit) in the
> > SARAM(or SARAM_A/_B) via the GUI BIOS/DSP Config interface. However
> > if I allocate the .cinit section in SDRAM and FlashBurn to the
> > FlashROM, it does not work (or boot).
> >
> > My application has to use the SDRAM for .cinit allocation. Did I
> > miss something or something in my linker and hex55 option is wrong?
>
> Where/when is your SDRAM initialized? Functions in the .cinit section
> (for example,
> auto_init) must run early -- before any C code runs, including DSP/BIOS
> -- so that
> means you would need some type of asm code at the _cint00 (entry point)
> vector to
> initialize SDRAM (i.e. correctly set 55x onchip EMIF registers).
>
> My guess is that SDRAM is not correctly initialized when auto_init()
> (and probably
> also BIOS_init) runs, therefore your C code fails because variables
> declared as const
> and static are not initialized correctly.
>
> > In the Linker option, I have
> > tried both the Run-Time Autoinitialization (-c) and the Load-Time
> > Initialization (-cr); the results are same.
>
> Load-time initialization would mean your Atmel code is handling C code
> variable
> initialization, which requires information in the COFF (.out) file which
> I think is
> not carried forward by hex55.exe. Such host code is fairly complex and
> requires a
> thorough understanding of the COFF format and specific TI enhancements
> to it --
> doesn't sound to me like you're doing that.
>
> To find out more about what .cinit does at run-time, search TI's site
> for
> auto-initialization.
>
> -Jeff
>
> > I have used the following Hex55 options in the convert command file:
> >
> > myApplication.out
> > -m2
> > -boot
> > -map myApplicationHex.map
> > -parallel16
> > -v5510:2
> > -o myAPplication.hex
> >
> > ROMS {
> > PAGE 0 : ROM : o=0x400000 , l = 0x80000
> > }
> >
> > Thanks for you help.
> >
> > Regards,
> >
> > Xiyu Shi
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467