|
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 |
|
|
Executing code from external SDRAM
Started by ●June 2, 2003
Reply by ●June 2, 20032003-06-02
|
--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? |
|
|
Reply by ●June 3, 20032003-06-03
|
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? |
|
|
Reply by ●June 4, 20032003-06-04
|
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.) |
Reply by ●June 5, 20032003-06-05
|
[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? |
|
|
Reply by ●June 5, 20032003-06-05
|
--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.) |
