DSPRelated.com
Forums

Executing code from external SDRAM

Started by matensil June 2, 2003
Hi all,

I have problems with external code execution from SDRAM. I have two
ADSP21065L sharing SDRAM on BANK0. I use VDSP++3.0. I loaded the
SDRAM initialization code in both processors.

The example given in application note 58 doesn't compile with VDSP3.0
because the linker does not want the SDRAM segment to be declared as
48 bit. I changed it to 32 bits, but it does not works. I tried to
use the PACKING option of the linker and it does not work better...

If someone can help me...

Regards



--On Monday, June 02, 2003 4:02 PM +0000 matensil <> wrote:

> I have problems with external code execution from SDRAM. I have two
> ADSP21065L sharing SDRAM on BANK0. I use VDSP++3.0. I loaded the
> SDRAM initialization code in both processors.

Maybe post your LDF and we can have a look. I don't know if it's needed but I
have the ELF option SHT_PROGBITS on the external section name. A typical code
memory and output section looks like this:

mem_ms0c0 { TYPE(PM RAM) START(0x00080000) END(0x0008ffff) WIDTH(32) }

out_ms0c0 SHT_PROGBITS
{
INPUT_SECTIONS($SLOWCODE0(seg_pmco))
INPUT_SECTIONS($FASTCODE(seg_ms0c0) $FASTCODE1(seg_ms0c0))
_end_ms0c0 = .;
} > mem_ms0c0

I use a combination of LDF macros and section directives in C to select which
code goes in which LDF output section.

> I changed it to 32 bits, but it does not works.

"does not work"? What does that mean?




Thanks Kenneth,

I tried the option SHT_PROGBITS but it behaves exactly the same way.
When I say "It does not work", It means :
- the disassembled instructions of the code in SDRAM are wrong
- the disassembled instructions of the code in SDRAM are changing each
time I make a step

I checked that there is no problems with the PCB and the refresh times
of SDRAM with a data section. The problems are only with code in SDRAM. Here is the LDF I use, if it can helps. It behaves the same way with
and without the PACKING option.

MEMORY
{
...
seg_SDRAM { TYPE(PM RAM) START(0x00020000) END(0x0002ffff) WIDTH(32)
}
}

MPMEMORY
{
master {START(0x00000100)}
slave {START(0x00000200)}
}

PROCESSOR master
{
KEEP( _main,___ctor_NULL_marker,___lib_end_of_heap_descriptions )
OUTPUT( $COMMAND_LINE_OUTPUT_FILE )
LINK_AGAINST(SDRAM.sm, slave.dxe)

SECTIONS
{...}
}

PROCESSOR slave{
OUTPUT($COMMAND_LINE_OUTPUT_DIRECTORY\slave.dxe)
LINK_AGAINST( SDRAM.sm )
SECTIONS
{...}
}

SHARED_MEMORY {
OUTPUT(SDRAM.sm)
LINK_AGAINST(SD631master.dxe)
SECTIONS{
seg_SDRAM
{
INPUT_SECTIONS(main.doj(seg_SDRAM) SDRAM.doj(seg_SDRAM))
//PACKING(6 B0 B0 B5 B6 B0 B0 B1 B2 B3 B4 B0 B0)
}>seg_SDRAM
}
} Regards
--- In , Kenneth Porter <kenneth_porter@k...> wrote:
> --On Monday, June 02, 2003 4:02 PM +0000 matensil <matensil@y...> wrote:
>
> > I have problems with external code execution from SDRAM. I have two
> > ADSP21065L sharing SDRAM on BANK0. I use VDSP++3.0. I loaded the
> > SDRAM initialization code in both processors.
>
> Maybe post your LDF and we can have a look. I don't know if it's
needed but I
> have the ELF option SHT_PROGBITS on the external section name. A
typical code
> memory and output section looks like this:
>
> mem_ms0c0 { TYPE(PM RAM) START(0x00080000) END(0x0008ffff) WIDTH(32) }
>
> out_ms0c0 SHT_PROGBITS
> {
> INPUT_SECTIONS($SLOWCODE0(seg_pmco))
> INPUT_SECTIONS($FASTCODE(seg_ms0c0) $FASTCODE1(seg_ms0c0))
> _end_ms0c0 = .;
> } > mem_ms0c0
>
> I use a combination of LDF macros and section directives in C to
select which
> code goes in which LDF output section.
>
> > I changed it to 32 bits, but it does not works.
>
> "does not work"? What does that mean?





Your LDF looks much fancier than mine. (I use separate LDF's with no shared
parts for my two CPU's and share memory by address convention rather than
symbolically.) However, it looks like it should work.

How do you load the system? Do you load from EPROM? It might be useful to
inspect the resulting hex file to see if the instructions look right in it. I
started doing this enough to deal with customizations to the loader that I
wrote a dump utility to more easily view the loader records in the hex file.

Another thing to check is whether you're using 0.3 silicon. We had all kinds
of mysterious problems with MP stuff when we tried to use earlier revs.

(Also, now that you're running code from external memory, be careful of
interrupt stuff. ADI just confirmed that the problems with the interrupt
controller seen in the 211xx are also present in the 65L. They're currently
confirming the specifics for inclusion in the errata document.)



[Please reply to the list, not directly to me.]

--On Thursday, June 05, 2003 9:41 AM +0000 matensil <> wrote:

> The silicon rev is 0.3, and I load the dxe with an APEX emulator. I
> first initialize SDRAM on both processors and then I reload the dxe
> and execute.

Ok. My setup has the SDRAM in the EPROM so it's initialized when the system
first powers up.

> I wonder if it can be an hardware problem because ADI support sent me
> an example code, and it doesn't work too. I thought my hardware was
> OK, because I tested the SDRAM with a data array, but maybe there are
> other hardware issues, or SDRAM parameter problem.

Quite possible. Have you looked at the many app notes ADI has on the SDRAM
controller?




--On Thursday, June 05, 2003 9:06 AM -0700 Kenneth Porter
<> wrote:

> Ok. My setup has the SDRAM in the EPROM so it's initialized when the system
> first powers up.

Doh, garbled that. That should be "SDRAM initialization in the boot loader
loaded from EPROM". (I use a customized version of 065l_prom.asm.)