We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I hope someone of you could help me. Using the AT91SAM9261 controller I've a few problems with the micron sdram 48LC8M16A2.
I wrote a little programm to test the sdram
unsigned char *var = (unsigned char *)0x20000000; //in the main function for(i=0;i<256;i++) { *var=i; var++; }
Unfortunately there are some errors.
(e.g. at adress 0x20000022 instead of 0x22 is there 0x02) (e.g. at adress 0x20000026 instead of 0x26 is there 0x06) (e.g. at adress 0x20000030 instead of 0x2E is there 0x0E) (e.g. at adress 0x20000036 instead of 0x36 is there 0x16) (e.g. at adress 0x20000040 instead of 0x3A is there 0x1A)
I check the values with the memory window, starting from 0x20000000. -> I get all theses errors.
But when I start a second window in the memory window with the start adr 0x20000036 (e.g.) I get the correct value at this position (not the false one)... How could that be possible?
best regards Gerhard
Might you have a timing error, possibly running the memories slightly too fast?
nearly at 100MHz - that should be ok. The atmel evaluation board is using nearly the same sdram device (also from micron, but a little bit bigger).
I'm not sure if there are big differences in the timing. The datasheets look very equal (have the same timing parameters) and at the moment I use the same initialization made by keil for this sdram. Only the configuration register is different (number of rows, column and so on...).
Different bits in the byte may because of tolerances have slightly different settle times resulting in some bits never (or very seldom) fail, while some bits often reads back the wrong contents.
I have made this test several times, and there are always the same errors (at the specific positions). Maybe it depends on the kind of this little test.
When running on the margin, you may also have a problem that the data is sampled just before the data has fully settled
It sounds that you mean it could also be a hardware problem? The hold / setup margin are very big - e.g. 0.8ns for the hold time. The longest trace is approximately 70mm and the shortest one is 35mm...
The signals are clean - but I will take a look at the timing, tomorrow.
If we assume a signal propacation of c/1.5, then you get about 0.18 ns extra propagation delay for the 35mm longer trace.
now I made an second test
unsigned char *ptr_sdram = (unsigned char *)0x20000000; for(i=0;i<256;i++) buf[i]=i; memcpy((void*)ptr_sdram,(void*)buf,256);
and this one is working without such problems (no value is wrong...)
Is there an big different to the above test example?
Obviously yes. First of all one works, the other doesn't, so there's clearly an important difference.
Second, memcpy() does a different job than that little loop. For starters, it has to work with two pointers, not just one. As a consequence of that, it's likely to work more slowly.
But no staring at C source code can possibly help with this puzzle. You have to look at generated assembly source code, and match that to oscillograms or logic analyser readings of the address, data and control lines of your memory interface. This is clearly a hardware issue.