SDRAM does not retain data

In my opinion, it's very strange.

But in your code you write a value to an arbitrary address of SDRAM, not dedicated to your variable...<div class='quotetop'>QUOTE </div>

--- Quote Start ---

sdram[43235]=0x00000000;[/b]

--- Quote End ---

I think u can try to allocate statically or dinamically some memory space for your variable.

Are you using a data cache? If so, you should be using the IO macros and/or the bit 31 override to circumvent the cache.

Alternately, you can use alt_uncached_malloc, which will return a pointer to an uncached location in memory. There are examples of this exact usage in the memtest software example.

Cheers,

- slacker

Slacker, I&#39;m not using a data cache (I&#39;m using Nios II/e) so I don&#39;t need to use uncached memory.

I tried using IORD/WR instructions and the result is the same:

#include <io.h># include <stdio.h># include "system.h"
int main()
{ 
    long i,j,k;
      long test,last;
      long values;
    long times;
    
    for(i=0;i<32;i++)
    {
  values=0;
  times=0;
    
    }
    for(i=0;i<10;i++)
      printf("Hello From Nios\n\n");
//    sdram=0x00000000;
    IOWR_32DIRECT(SDRAM_BASE, 3578, 0x00000000);
    last=0;
    i=0;
    j=0;
    while(1)
    {
  //test=sdram;
  test=IORD_32DIRECT(SDRAM_BASE, 3578);
  if(test!=last)
  {
      times=i;
      values=test;
      last=test;
      j++;
  }
  if (test==0xffffffff)
  {
      for(k=0;k<32;k++)
    printf("\nTime:%8ld us Value: %8x",times,values);
      break;
  }
  usleep(i);
  i+=1; //INCREMENT x us
    }
  return 0;
}

...I noticed that using a delay increment of 1us at a time (see line "i+=1; //INCREMENT x us") , the problem appears earlier than when I use an increment of 100us:

1us output:

Time: 175 us Value: 8

Time: 180 us Value: 400008

Time: 184 us Value: 40000c

Time: 187 us Value: c0000c

Time: 189 us Value: c4000c

Time: 190 us Value: 40c4000c

Time: 191 us Value: 44c4200c

Time: 194 us Value: 44d4202c

Time: 195 us Value: 44d4203c

Time: 196 us Value: 44f5203c

Time: 199 us Value: 54f7203c

Time: 202 us Value: 54f7223c

Time: 203 us Value: 74f7223c

Time: 204 us Value: 7cf7223c

Time: 205 us Value: 7cf72a7c

Time: 206 us Value: 7cf7aa7d

Time: 209 us Value: 7cf7ea7d

Time: 210 us Value: 7df7ea7d

Time: 215 us Value: 7df7ee7d

Time: 219 us Value: fdf7ee7d

Time: 228 us Value: fdf7eefd

Time: 242 us Value: fdf7eeff

Time: 253 us Value: fdf7efff

Time: 254 us Value: fdffffff

Time: 255 us Value: ffffffff

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

100us output:

Time: 2500 us Value: 8

Time: 2600 us Value: 40000c

Time: 2700 us Value: 44f4203c

Time: 2800 us Value: 7cf7227d

Time: 2900 us Value: 7df7ea7d

Time: 3000 us Value: fdf7ee7d

Time: 3100 us Value: fdf7eefd

Time: 3300 us Value: fdf7efff

Time: 3400 us Value: ffffffff

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

Time: 0 us Value: 0

It doesn&#39;t seem an overwriting problem. Another thing: I&#39;m running the program on onchip memory, since if I set the reset address at the beginning of the SDRAM, I can&#39;t get debug to the first line of the code.

Sounds like a hardware issue, to me. In fact, it sounds (to me) like your memory is somehow expecting the controller to refresh it.... The Altera-provided controller, for SDRAMs, only supports auto-refresh memories and configures these memories to go into auto-refresh mode during initialization.

I would say that you have some sort of initialization issue, or, perhaps, a bad SDRAM. Continuing with a pure SW debug is a dead-end.

Best of luck!

- slacker

I think you are writing to somewhere other than SDRAM. The MT48LC4M32B2 is a 128M-bit device organized as 4M x 32 bits. So, I think the highest index into a long array is 4095, and an index of 43235 points to who knows where.

I would use the debugger and check to see what locations actually get written when using index 0, 1, and 2 to start with and check memory after each write.

You could also make your array pointers to integers or characters, and thereby increase the number of accessable elements (4096 longs (32-bits each) is the same as 4 x 4096 chars (8-bits each).

Marco,

The description of your problem suggests that may be an issue with the SDRAM timings. Things you need to check: 1) verify if the time settings in SOPC builder correspond with those in the chip datasheet (do not randomly try different values, just use the ones given in the datasheet);

2) adjust the phase for the SDRAM clock (I&#39;m assuming you are using a dedicated clock output from the PLL) - this is very important in order to get it to work. Usually a negative phase in the range [-pi/3:-pi/6] for the SDRAM clock works for me - you will have to use a scope and little experimentation here, because this is highly dependent of the physical characteristics of your board and the clock speed.

Also you mentioned that if you set the reset address at the beginning of the SDRAM the system doesn&#39;t start. This is normal because the reset address needs to point to a bootloader code of some sort, so you need to set this to a nonvolatile memory, or on-chip memory.

Good luck

C

Dear all,

thank you for your kind replies.

Clancy, about 1) it should be ok, since the SDRAM I use is among the presets of the SDRAM controller module in SOPC builder.

Point 2) of your reply is very interesting to me and I&#39;m going to check it out now.

I&#39;ll let you know the outcome of my try!

Cheers,

Marco

Well, I tried with different phase-shifts for sdram with no success. Now I&#39;m doing the tests on location 0 of the SDRAM, even if I&#39;m quite sure that 43235 is in the range.

Now I&#39;m waiting a reply from the altera support....

Cheers

Marco

Marco,

just want to emphasize Clancy&#39;s point regarding the SDRAM clock phase. This phase seems to be very critical (at least at higher CPU clocks), and it depends on place & route.

In my specific design I had to ...

1) lock down the SDRAM-controller to a logic lock region close to SDRAM IO pins in order to freeze timing

2) adjust PLL parameters manually in the chip editor to values I was not able to get using the wizard.

Failing to do so resulted in arbitrary error patterns ranging from steady failure up to passing memory tests with data read/write but sporadic failures during code execution.

Rolf