Hello,

I have had a scan on the schematic, and as of now I have not found any kind of visible problems. The layout considerations are important too I guess. You have to make sure of the bypass capacitors with minimum distance from the related pins as on the SAM7 datasheet. I would say also check for the presence of the clock on the SDRAM clock, the chip should not be far away from the SAM7 chip on the board.

Thank you and regards.

--- On Thu, 12/4/08, matthiasbuhl wrote:
From: matthiasbuhl
Subject: [AT91SAM] Re: AT91SAM7SE512 and K4S561632J SDRAM Problems
To: A...@yahoogroups.com
Date: Thursday, December 4, 2008, 1:16 PM

Hello,

First of all - thank you very much for looking into my problem. I

uploaded the schematics of my project and the SDRAM init routines.

After running into that problem I ordered the Micron 48LC16M16A2- 75

(to test if an replacement would solve the problem) and the

corresponding industrial part (since the final application has to

fulfill industrial standards) but it takes some time until they arrive

(that's why I took the Samsung part at first). I hope that a

replacement is working otherwise my Schematics or Layout might be wrong.

I still don't understands why SDRAM should be so sensitive. I still

think one should be able to replace the Micron with the Samsung

device, but it seems (as my problem proofs assuming the schematics is

OK) that there is some hidden difference that I don't find in the

datasheets.

My board of course differs somewhat from the Atmel EK-Board

(positioning, layout) and maybe the problem lies in that. My boards are

manufactured by a company so I don't know if there some special

soldering going on or not.

Maybe you see some flaw I didn't recognized yet. Thanks for your help.

Matthias

--- In AT91SAM@yahoogroups .com, Maziar Tasbihi wrote:

>

> Hello,

>

> With regards to SDRAM operation, I would say that you cannot simply

change the Micron type for the Samsung type because the datasheets are

the same. I would say, that if you have etched the board exactly like

the one you are using as the evaluation board, I mean exactly the same

pin to pin, and power ratings and everything, then just try to get the

Micron part for the SDRAM. But can you tell me, how did you solder the

SDRAM part in, the soldering of the SDRAM is very delicate as well.

> I would also say, that if you cannot find the Micron part, just try

to order a few from your local store, it is worth it to make sure that

your board works ok, and if not, then you may be very lucky and

scavenge a couple from old SDRAM parts for the x86 pentium 3, some of

them were manufactured by Micron.

> Would I be asking for too much to ask for the schematics you are

talking about exactly as you have used it ?

>

> Thank you and regards.

>

> --- On Thu, 12/4/08, matthiasbuhl wrote:

> From: matthiasbuhl

> Subject: [AT91SAM] Re: AT91SAM7SE512 and K4S561632J SDRAM Problems

> To: AT91SAM@yahoogroups .com

> Date: Thursday, December 4, 2008, 5:40 AM

>

>

>

>

>

>

>

>

>

>

>

> I used some test routines like:

>

>

>

> volatile unsigned char *ptr = (volatile unsigned char*)SDRAM_ ADDRESS;

>

> for(i=0;i<256; i++)

>

> {

>

> *ptr=i;

>

> ptr++;

>

> }

>

>

>

> I get a different result compared to a routine like

>

>

>

> volatile unsigned char *ptr = (volatile unsigned char*)SDRAM_ ADDRESS;

>

> unsigned char buf[256];

>

> for(i=0;i<256; i++)

>

> buf[i]=i;

>

> memcpy((void* )ptr,(void* )buf,256) ;

>

>

>

> Almost all bytes are correct, but some are wrong. Sometimes completely

>

> new values, sometimes a repeat of the value before. If I call one of

>

> the subroutines I get always the same bytes with the same values wrong.

>

>

>

> I guess the compiler sets up memcpy and *ptr=i differently and

>

> therefore the wrong bytes differ in each routine. But I'm unable to

>

> draw any conclusion from it. Still have the feeling that some of the

>

> init parameters like TRC,TRP,etc. are wrong. And it seems that writing

>

> is corrupted not reading.

>

>

>

> Can anybody help me?

>

> Matthias

>

>

>

> --- In AT91SAM@yahoogroups .com, "matthiasbuhl"

wrote:

>

> >

>

> > Hello,

>

> >

>

> > I created a circuit (PCB) identical to the AT91SAM7SE512- EK with

>

> > respect to the SDRAM and NAND-FLASH. The only difference is that I use

>

> > the Samsung K4S561632J-UI75 instead of the Micron 48LC16M16A2- 75. The

>

> > two parts should have the same characteristics regarding SDRAM

>

> > operation and timing.

>

> > For initialization I use the code as suggested in the Application Note

>

> > "Using SDRAM on AT91SAM7SE Microcontrollers" .

>

> >

>

> > Nevertheless my software accessing the SDRAM is working on the

>

> > Evaluation Board but not on my own created PCB (all other aspects of

>

> > my software are working on both boards). I just perform read and write

>

> > operation using some pointers.

>

> >

>

> > If I read/write a block of data using SDRAM I end up with some false

>

> > bytes (most of the data block is correct). The process is repeatable

>

> > in the case that the same bytes will be false when performing the same

>

> > operation (like reading a page from NAND-Flash and transmitting the

>

> > data via USART). The bytes are not broken since I can write any value

>

> > to them afterwards.

>

> >

>

> > I hope that somebody had run into something similiar and knows some

>

> > advice. I'm lost here since it's my first time working with SDRAMs

>

> > (and AT91SAM7). Changing the timing parameters of the SDRAMC_CR did

>

> > not work and the Micron 48LC16M16A2- 75 values should work for the

>

> > Samsung device as far as I can see (comparing the datasheets). But

>

> > maybe I overlooked something since I also cannot find the TXSR value

>

> > for the Samsung K4S561632J-UI75.

>

> >

>

> > The error is difficult to grasp since most of the data operations on

>

> > the SDRAM is alright and everthing works on the Evaluation Board. And,

>

> > I have two PCBs manufactured and both show the same failures (so

>

> > probably no broken chip/pin)

>

> >

>

> > Thanks for any advice you could give,

>

> > Matthias

>

> >

>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hello,

Thanks for having a look to my schematics. I somehow have to restate
my problem. I wrote a test-subroutine that's writing some pattern to
the SDRAM (see uploaded file: test2-source-code.txt). It seems that
every time I call the test routine there are several bytes who contain
wrong values afterwards. These bytes are almost the same in every
calling of the test. Furthermore there are some of these bytes which
change their (wrong) values in every test call. It's always only some
of the wrong bytes that are changing their values but always different
ones. So there is some dynamics/noise/toggling going on (see uploaded
file: test2-repeat-1+sr01-A.txt).

My two boards behave similar but the bytes and number of wrong bytes
are a little different. The pattern is the same. And still the Atmel
Evaluation Board with the Micron SDRAM is doing just fine with the
same software.

Because of the dynamics now I also though that my layout might be
wrong or bad. It was a quick and dirty design and not all is optimal.
I need to change that, maybe. I uploaded it also (see file:
2008-12-04-layout.jpg).

I also thing that maybe the processor (some registers) is broken, but
on two boards?

Thanks to everyone who might have an advice here. Maybe someone ran
into similar problem with an SDRAM.

Matthias
--- In A...@yahoogroups.com, Maziar Tasbihi wrote:
>
> Hello,
>
> I have had a scan on the schematic, and as of now I have not found
any kind of visible problems. The layout considerations are important
too I guess. You have to make sure of the bypass capacitors with
minimum distance from the related pins as on the SAM7 datasheet. I
would say also check for the presence of the clock on the SDRAM clock,
the chip should not be far away from the SAM7 chip on the board.
>
> Thank you and regards.
>
> --- On Thu, 12/4/08, matthiasbuhl wrote:
> From: matthiasbuhl
> Subject: [AT91SAM] Re: AT91SAM7SE512 and K4S561632J SDRAM Problems
> To: A...@yahoogroups.com
> Date: Thursday, December 4, 2008, 1:16 PM
>
> Hello,
>
> First of all - thank you very much for looking into my problem. I
>
> uploaded the schematics of my project and the SDRAM init routines.
>
> After running into that problem I ordered the Micron 48LC16M16A2- 75
>
> (to test if an replacement would solve the problem) and the
>
> corresponding industrial part (since the final application has to
>
> fulfill industrial standards) but it takes some time until they arrive
>
> (that's why I took the Samsung part at first). I hope that a
>
> replacement is working otherwise my Schematics or Layout might be wrong.
>
> I still don't understands why SDRAM should be so sensitive. I still
>
> think one should be able to replace the Micron with the Samsung
>
> device, but it seems (as my problem proofs assuming the schematics is
>
> OK) that there is some hidden difference that I don't find in the
>
> datasheets.
>
> My board of course differs somewhat from the Atmel EK-Board
>
> (positioning, layout) and maybe the problem lies in that. My boards are
>
> manufactured by a company so I don't know if there some special
>
> soldering going on or not.
>
> Maybe you see some flaw I didn't recognized yet. Thanks for your help.
>
> Matthias
>
> --- In AT91SAM@yahoogroups .com, Maziar Tasbihi wrote:
>
> > > Hello,
>
> > > With regards to SDRAM operation, I would say that you cannot simply
>
> change the Micron type for the Samsung type because the datasheets are
>
> the same. I would say, that if you have etched the board exactly like
>
> the one you are using as the evaluation board, I mean exactly the same
>
> pin to pin, and power ratings and everything, then just try to get the
>
> Micron part for the SDRAM. But can you tell me, how did you solder the
>
> SDRAM part in, the soldering of the SDRAM is very delicate as well.
>
> > I would also say, that if you cannot find the Micron part, just try
>
> to order a few from your local store, it is worth it to make sure that
>
> your board works ok, and if not, then you may be very lucky and
>
> scavenge a couple from old SDRAM parts for the x86 pentium 3, some of
>
> them were manufactured by Micron.
>
> > Would I be asking for too much to ask for the schematics you are
>
> talking about exactly as you have used it ?
>
> > > Thank you and regards.
>
> > > --- On Thu, 12/4/08, matthiasbuhl wrote:
>
> > From: matthiasbuhl > Subject: [AT91SAM] Re: AT91SAM7SE512 and K4S561632J SDRAM Problems
>
> > To: AT91SAM@yahoogroups .com
>
> > Date: Thursday, December 4, 2008, 5:40 AM
>
> > > > > > > > > > > >
>
> > I used some test routines like:
>
> > > > > volatile unsigned char *ptr = (volatile unsigned char*)SDRAM_ ADDRESS;
>
> > > for(i=0;i<256; i++)
>
> > > {
>
> > > *ptr=i;
>
> > > ptr++;
>
> > > }
>
> > > > > I get a different result compared to a routine like
>
> > > > > volatile unsigned char *ptr = (volatile unsigned char*)SDRAM_ ADDRESS;
>
> > > unsigned char buf[256];
>
> > > for(i=0;i<256; i++)
>
> > > buf[i]=i;
>
> > > memcpy((void* )ptr,(void* )buf,256) ;
>
> > > > > Almost all bytes are correct, but some are wrong. Sometimes completely
>
> > > new values, sometimes a repeat of the value before. If I call one of
>
> > > the subroutines I get always the same bytes with the same values
wrong.
>
> > > > > I guess the compiler sets up memcpy and *ptr=i differently and
>
> > > therefore the wrong bytes differ in each routine. But I'm unable to
>
> > > draw any conclusion from it. Still have the feeling that some of the
>
> > > init parameters like TRC,TRP,etc. are wrong. And it seems that writing
>
> > > is corrupted not reading.
>
> > > > > Can anybody help me?
>
> > > Matthias
>
> > > > > --- In AT91SAM@yahoogroups .com, "matthiasbuhl" wrote:
>
> > > > > > > Hello,
>
> > > > > > > I created a circuit (PCB) identical to the AT91SAM7SE512- EK with
>
> > > > respect to the SDRAM and NAND-FLASH. The only difference is that
I use
>
> > > > the Samsung K4S561632J-UI75 instead of the Micron 48LC16M16A2-
75. The
>
> > > > two parts should have the same characteristics regarding SDRAM
>
> > > > operation and timing.
>
> > > > For initialization I use the code as suggested in the
Application Note
>
> > > > "Using SDRAM on AT91SAM7SE Microcontrollers" .
>
> > > > > > > Nevertheless my software accessing the SDRAM is working on the
>
> > > > Evaluation Board but not on my own created PCB (all other aspects of
>
> > > > my software are working on both boards). I just perform read and
write
>
> > > > operation using some pointers.
>
> > > > > > > If I read/write a block of data using SDRAM I end up with some false
>
> > > > bytes (most of the data block is correct). The process is repeatable
>
> > > > in the case that the same bytes will be false when performing
the same
>
> > > > operation (like reading a page from NAND-Flash and transmitting the
>
> > > > data via USART). The bytes are not broken since I can write any
value
>
> > > > to them afterwards.
>
> > > > > > > I hope that somebody had run into something similiar and knows some
>
> > > > advice. I'm lost here since it's my first time working with SDRAMs
>
> > > > (and AT91SAM7). Changing the timing parameters of the SDRAMC_CR did
>
> > > > not work and the Micron 48LC16M16A2- 75 values should work for the
>
> > > > Samsung device as far as I can see (comparing the datasheets). But
>
> > > > maybe I overlooked something since I also cannot find the TXSR value
>
> > > > for the Samsung K4S561632J-UI75.
>
> > > > > > > The error is difficult to grasp since most of the data operations on
>
> > > > the SDRAM is alright and everthing works on the Evaluation
Board. And,
>
> > > > I have two PCBs manufactured and both show the same failures (so
>
> > > > probably no broken chip/pin)
>
> > > > > > > Thanks for any advice you could give,
>
> > > > Matthias
>
> > > >
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )