running sw in SDRAM

--- Quote Start ---

originally posted by victors@Jan 3 2006, 01:57 PM

i use sdram for most of my projects and have never had a problem. looks like normal memory.

a few things to check: maybe you have a screw-up with the stack or something.

* compile a program to run only from sdram. if that works then you might have screw-up pointers.

--- Quote End ---

I tried also a small program running only from SDRAM, no luck.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

* How have you compiled the code? Most of time the functions are not relocatable. Have you compiled the code for that specific location in SDRAM or just copied it there?[/b]

--- Quote End ---

I added a section in the linkerscript and then used the __attribute((.section(".sdram"))) on the function. I verified in on object dump, and it seems to be ok.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

*Where are the local variables stored?[/b]

--- Quote End ---

in SRAM, only one global integer to test.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

*When the function returns where does it return to?[/b]

--- Quote End ---

I hope to the place where it was called from.

Here&#39;s the small test function :

volatile int ga = 0;
void TestSDRam() __attribute__ ((section (".sdram")));
void TestSDRam()
{
    __asm__("NOP");
    __asm__("NOP");
    __asm__("NOP");
    __asm__("NOP");
    ga++;
}

This function gets compiled to :

Disassembly of section .sdram:
01000000 <_Z9TestSDRamv>:
 1000000:    0001883a  nop
 1000004:    0001883a  nop
 1000008:    0001883a  nop
 100000c:    0001883a  nop
 1000010:    00c00534  movhi    r3,20
 1000014:    18c6d404  addi    r3,r3,6992
 1000018:    18800037  ldwio    r2,0(r3)
 100001c:    10800044  addi    r2,r2,1
 1000020:    18800035  stwio    r2,0(r3)
 1000024:    f800283a  ret

This function is called from somewhere else in the sw, and I print out the memory contents before the call, so I can verify the code is still there :

void foo()
{
  volatile int* a = (int*) na_SDRAM;
          
  for (int k = 0; k < 40; k++)
  {
      printf("%08x : %08x \r", a, *a);
      a++; 
  }
  TestSDRam();
  printf("ga : %d\r", ga);
}

The result :

01000000 : 0001883a
01000004 : 0001883a
01000008 : 0001883a
0100000c : 0001883a
01000010 : 00c00534
01000014 : 18c6d404
01000018 : 18800037
0100001c : 10800044
01000020 : 18800035
01000024 : f800283a
01000028 : 32463032
0100002c : 31303343
01000030 : 32423030
01000034 : 31303443
01000038 : 34303030
0100003c : 46464245
01000040 : 41374544
01000044 : 31333033
01000048 : 36423030
0100004c : 33530a0d
01000050 : 30303531
01000054 : 30343030
01000058 : 34303033
0100005c : 46374646
01000060 : 35314645
01000064 : 30343130
01000068 : 35314644
0100006c : 30303030
01000070 : 35314544
01000074 : 30384630
01000078 : 35363844
0100007c : 33530a0d
01000080 : 30303531  
** START BOOTLOADER **

The processor starts again at its reset address.

Yesterday, I tried the same, and the processor didn&#39;t restart, the only change was that I didn&#39;t use the -G0 compiler option to get rid of the global pointer. Still the integer &#39;ga&#39; was nopt modified.

With the use of the global pointer, I have this disassembled code :

01000000 <_Z9TestSDRamv>:
 1000000:    0001883a  nop
 1000004:    0001883a  nop
 1000008:    0001883a  nop
 100000c:    0001883a  nop
 1000010:    d0a00337  ldwio    r2,-32756(gp)
 1000014:    10800044  addi    r2,r2,1
 1000018:    d0a00335  stwio    r2,-32756(gp)
 100001c:    f800283a  ret

The only difference here seems to be the use of register r3. I can not understand why this changes the effect on calling the function.

Stefaan