Problems with SDRAM and Altera Cyclone

I have a custom board with an altera EP1C12, a flash memory and a MT48LC4M32B2 SDRAM memory. Timings I set in SOPC builder are the default timings for this part.

When I set the value 0x00000000 to a particular location (it doesn't matter which location I choose), if I read back the same location after

5 ms (milliseconds!) I find 0x00000000; after 10ms some of the bits go to value 1; incrementally all the bits go to 1, and if I read it after 15ms, I read 0xffffffff.

I tried increasing the refresh frequency (from 15.625us to 3us) with no success.

here is the test code, run from on-chip memory:

#include #include #include "system.h"

int main() { long i,j,k; long test,last; long values[32]; long times[32];

for(i=0;i

Reply to
BQ
Loading thread data ...

Hi, Sorry I can't solve your problem regarding why the SDRAM is breaking - but there is a little bug in the code - which may explain why the time to failure is different for different time increment values: the lines: usleep(i); i+=1; //INCREMENT x us should be: usleep(inc_val) i+=inc_val;

as for an inc-val of 1 the first few loops this happens:

loop real_time value of i=usleep time

1 1 1 2 2 2 3 4 3 4 7 4 etc...

The real time is incorrect versus what i is saying it is. Maybe if you change the code, you may see that the time to failure is the same for different inc-values.

good luck! Cheers, John

BQ wrote:

--
***********************************************************************

/ /\/  John McGrath
\ \    Xilinx Inc.           
       Mixed Signal IC Design Engineer
\_\/\                        
                   
  Telephone: +353 21 4355 704        
  FAX:  
  John.McGrath@xilinx.com   
                X I L I N X  I N C.                       
***********************************************************************
Reply to
John McGrath

At first glance it would look as if your refresh is not happening at all however...

This seems to point to data corruption happening as you read the memory. I would check that you're meeting the timing on CS, RAS, CAS and (especially) WE.

Reply to
Gabor

Hello John, thank you for spending time for my problem :-) In fact, successive tests show that you are right, the time to failure is not dependent on the time between reads. Cheers Marco

Reply to
BQ

We checked with an oscilloscope and it appears the refresh signal is ok...

I'm asking myself whether slowing down the SDRAM clock can be a solution... THhank you very much, BQ

Reply to
BQ

Hello:

I'm using 2 Micron SDRAMs MT48LC16M16A2TG-75IT

This is one of the only components that came up at the start without any coaxing on my part.

However I'm using Quartus 4.1 When I got a copy of 4.2 it seemed to drop buuilt in support for SDRAMs. I've got another copy of 4.2 and looks like it's back. I'm on a deadline so I won't change anything for a bit.

gm

Reply to
GMM50

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.