Sign in
Search AT91SAM
Subscribe to AT91SAM
New!
Discussion Groups
See Also
Discussion Groups | AT91SAM ARM | Re: AT91SAM7SE512 and K4S561632J SDRAM Problems
For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - matthiasbuhl - Dec 9 11:31:57 2008
Hello,
I checked application notes for the SDRAM layout and found that my
layout is far from being perfect. I really have to clean up my board,
but I'm not quite sure is the bad wiring is really the cause for my
problems.
Further investigations came up with this: As long as I don't send any
command to the NANDFLASH the SDRAM is working fine!! As soon as I send
the first command to the NANDFLASH (which is a reset command in the
initialization) the SDRAM is showing the above stated behavior (some
bytes are wrong in the writing process). I don't understand this. The
NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
and the input pins of the NANDFLASH should be high-z and therefore
unresponsible. Why is the SDRAM still affected.
Can I somehow measure if the NANDFLASH pins are back to high-z? What
other changes of the NANDFLASH state do we have after the first reset
command (some clock maybe turned on)?
The more I look into that problem the confused I am. I'm very happy to
get new hints or advices.
Matthias
Report this post
--- In A...@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
>
------------------------------------
______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
I checked application notes for the SDRAM layout and found that my
layout is far from being perfect. I really have to clean up my board,
but I'm not quite sure is the bad wiring is really the cause for my
problems.
Further investigations came up with this: As long as I don't send any
command to the NANDFLASH the SDRAM is working fine!! As soon as I send
the first command to the NANDFLASH (which is a reset command in the
initialization) the SDRAM is showing the above stated behavior (some
bytes are wrong in the writing process). I don't understand this. The
NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
and the input pins of the NANDFLASH should be high-z and therefore
unresponsible. Why is the SDRAM still affected.
Can I somehow measure if the NANDFLASH pins are back to high-z? What
other changes of the NANDFLASH state do we have after the first reset
command (some clock maybe turned on)?
The more I look into that problem the confused I am. I'm very happy to
get new hints or advices.
Matthias
Report this post
--- In A...@yahoogroups.com, "matthiasbuhl"
>
> 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
>
------------------------------------
______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - tasbihmr - Dec 9 11:42:24 2008
Hello,
You said that this is a SAM7s on your board. If I had to make a board
for example, then I would try some kind of debug features. I mean, try
something like building the parts of your system one at a time. Now,
if you could for example go after the SDRAM first, then why not try
that? Or why not try to go after the NAND first? The behavior you say,
will be more definable at least.
Thank you and regards.
--- In A...@yahoogroups.com, "matthiasbuhl" wrote:
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
>
> Matthias
> Report this post
>
> --- In A...@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 )
You said that this is a SAM7s on your board. If I had to make a board
for example, then I would try some kind of debug features. I mean, try
something like building the parts of your system one at a time. Now,
if you could for example go after the SDRAM first, then why not try
that? Or why not try to go after the NAND first? The behavior you say,
will be more definable at least.
Thank you and regards.
--- In A...@yahoogroups.com, "matthiasbuhl"
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
>
> Matthias
> Report this post
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > 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 )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - Rick Collins - Dec 9 11:45:41 2008
--- In A...@yahoogroups.com, "matthiasbuhl" wrote:
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
A NAND flash still has to have it's chip enable asserted in order for
the output to be enabled. Is the chip select enabled when it
shouldn't be?
Rick
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
A NAND flash still has to have it's chip enable asserted in order for
the output to be enabled. Is the chip select enabled when it
shouldn't be?
Rick
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - matthiasbuhl - Dec 9 11:51:14 2008
I also reduced the Master CLock from 48MHz to 24MHz to see if
crosstalk is the cause (if it is bad layout) but there was no effect.
Matthias
--- In A...@yahoogroups.com, "matthiasbuhl" wrote:
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
>
> Matthias
> Report this post
>
> --- In A...@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 )
crosstalk is the cause (if it is bad layout) but there was no effect.
Matthias
--- In A...@yahoogroups.com, "matthiasbuhl"
>
> Hello,
>
> I checked application notes for the SDRAM layout and found that my
> layout is far from being perfect. I really have to clean up my board,
> but I'm not quite sure is the bad wiring is really the cause for my
> problems.
>
> Further investigations came up with this: As long as I don't send any
> command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> the first command to the NANDFLASH (which is a reset command in the
> initialization) the SDRAM is showing the above stated behavior (some
> bytes are wrong in the writing process). I don't understand this. The
> NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> and the input pins of the NANDFLASH should be high-z and therefore
> unresponsible. Why is the SDRAM still affected.
>
> Can I somehow measure if the NANDFLASH pins are back to high-z? What
> other changes of the NANDFLASH state do we have after the first reset
> command (some clock maybe turned on)?
>
> The more I look into that problem the confused I am. I'm very happy to
> get new hints or advices.
>
> Matthias
> Report this post
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > 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 )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - matthiasbuhl - Dec 9 11:55:42 2008
The chip enabled /CE line should be set to high (disable NAND) after
NAND operation is finished, right and my software is doing it. Today I
have a oscilloscope here and start measuring some of the wires to see
if it is really as it should be. Thanks for the advice.
Matthias
--- In A...@yahoogroups.com, "Rick Collins" wrote:
>
> --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
>
> A NAND flash still has to have it's chip enable asserted in order for
> the output to be enabled. Is the chip select enabled when it
> shouldn't be?
>
> Rick
>
------------------------------------
______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
NAND operation is finished, right and my software is doing it. Today I
have a oscilloscope here and start measuring some of the wires to see
if it is really as it should be. Thanks for the advice.
Matthias
--- In A...@yahoogroups.com, "Rick Collins"
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
>
> A NAND flash still has to have it's chip enable asserted in order for
> the output to be enabled. Is the chip select enabled when it
> shouldn't be?
>
> Rick
>
------------------------------------
______________________________
TI's C2000™ microcontrollers controlSUITE™ Desktop gives you instant access to all supporting software libraries, training, collateral, and more!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - matthiasbuhl - Dec 9 12:00:44 2008
Hi, you are right. I should go back to a simple software and see when
the problem ticks in. I will do so (when my hardware checks are done)
but haven't done so yet, since I know my complete software is working
on the similar Atmel AT91SAM7SE512-EK Board. I also skipped either
SDRAM or NAND init and then each of it is working but not together.
I hope not to be crazy when this problem is finally solved. Thank you,
Matthias
--- In A...@yahoogroups.com, "tasbihmr" wrote:
>
> Hello,
>
> You said that this is a SAM7s on your board. If I had to make a board
> for example, then I would try some kind of debug features. I mean, try
> something like building the parts of your system one at a time. Now,
> if you could for example go after the SDRAM first, then why not try
> that? Or why not try to go after the NAND first? The behavior you say,
> will be more definable at least.
>
> Thank you and regards.
>
> --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
> >
> > Matthias
> >
> >
> > Report this post
> >
> > --- In A...@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
> > >
>
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
the problem ticks in. I will do so (when my hardware checks are done)
but haven't done so yet, since I know my complete software is working
on the similar Atmel AT91SAM7SE512-EK Board. I also skipped either
SDRAM or NAND init and then each of it is working but not together.
I hope not to be crazy when this problem is finally solved. Thank you,
Matthias
--- In A...@yahoogroups.com, "tasbihmr"
>
> Hello,
>
> You said that this is a SAM7s on your board. If I had to make a board
> for example, then I would try some kind of debug features. I mean, try
> something like building the parts of your system one at a time. Now,
> if you could for example go after the SDRAM first, then why not try
> that? Or why not try to go after the NAND first? The behavior you say,
> will be more definable at least.
>
> Thank you and regards.
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
> >
> > Matthias
> >
> >
> > Report this post
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl"
> > >
> > > 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
> > >
>
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - Rick Collins - Dec 9 12:59:55 2008
Changing the clock rate will do little to change crosstalk. Crosstalk
is caused by a fast edge rate, not the frequency. Just changing the
clock frequency does little. You should be able to inspect the layout
to find potential crosstalk problems. Traces on adjacent layers
running above one another is the only configuration that contributes
significantly to crosstalk. Do you have any traces that run parallel
more than a couple of inches on adjacent layers?
Rick
--- In A...@yahoogroups.com, "matthiasbuhl" wrote:
>
> I also reduced the Master CLock from 48MHz to 24MHz to see if
> crosstalk is the cause (if it is bad layout) but there was no effect.
>
> Matthias
>
> --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
> >
> > Matthias
> >
> >
> > Report this post
> >
> > --- In A...@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
> > >
>
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
is caused by a fast edge rate, not the frequency. Just changing the
clock frequency does little. You should be able to inspect the layout
to find potential crosstalk problems. Traces on adjacent layers
running above one another is the only configuration that contributes
significantly to crosstalk. Do you have any traces that run parallel
more than a couple of inches on adjacent layers?
Rick
--- In A...@yahoogroups.com, "matthiasbuhl"
>
> I also reduced the Master CLock from 48MHz to 24MHz to see if
> crosstalk is the cause (if it is bad layout) but there was no effect.
>
> Matthias
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > Hello,
> >
> > I checked application notes for the SDRAM layout and found that my
> > layout is far from being perfect. I really have to clean up my board,
> > but I'm not quite sure is the bad wiring is really the cause for my
> > problems.
> >
> > Further investigations came up with this: As long as I don't send any
> > command to the NANDFLASH the SDRAM is working fine!! As soon as I send
> > the first command to the NANDFLASH (which is a reset command in the
> > initialization) the SDRAM is showing the above stated behavior (some
> > bytes are wrong in the writing process). I don't understand this. The
> > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > after working on the NANDFLASH the /CE line of the NANDFLASH goes HIGH
> > and the input pins of the NANDFLASH should be high-z and therefore
> > unresponsible. Why is the SDRAM still affected.
> >
> > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > other changes of the NANDFLASH state do we have after the first reset
> > command (some clock maybe turned on)?
> >
> > The more I look into that problem the confused I am. I'm very happy to
> > get new hints or advices.
> >
> > Matthias
> >
> >
> > Report this post
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl"
> > >
> > > 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
> > >
>
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - matthiasbuhl - Dec 9 14:08:13 2008
Maybe you are right but I thought a lower clock frequency of the CLK
line of the Synchronous DRAM will be better. I guess the higher the
frequency the shorter the adjacent traces that can crosstalk (like
antennas with length equal to multiples of the wavelength). On my bad
layout the clock line is running a rather unnecessary long way
adjacent to other traces etc.
Cheers,
Matthias
--- In A...@yahoogroups.com, "Rick Collins" wrote:
>
> Changing the clock rate will do little to change crosstalk. Crosstalk
> is caused by a fast edge rate, not the frequency. Just changing the
> clock frequency does little. You should be able to inspect the layout
> to find potential crosstalk problems. Traces on adjacent layers
> running above one another is the only configuration that contributes
> significantly to crosstalk. Do you have any traces that run parallel
> more than a couple of inches on adjacent layers?
>
> Rick
>
> --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> >
> > I also reduced the Master CLock from 48MHz to 24MHz to see if
> > crosstalk is the cause (if it is bad layout) but there was no effect.
> >
> > Matthias
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> > >
> > > Hello,
> > >
> > > I checked application notes for the SDRAM layout and found that my
> > > layout is far from being perfect. I really have to clean up my
board,
> > > but I'm not quite sure is the bad wiring is really the cause for my
> > > problems.
> > >
> > > Further investigations came up with this: As long as I don't
send any
> > > command to the NANDFLASH the SDRAM is working fine!! As soon as
I send
> > > the first command to the NANDFLASH (which is a reset command in the
> > > initialization) the SDRAM is showing the above stated behavior (some
> > > bytes are wrong in the writing process). I don't understand
this. The
> > > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > > after working on the NANDFLASH the /CE line of the NANDFLASH
goes HIGH
> > > and the input pins of the NANDFLASH should be high-z and therefore
> > > unresponsible. Why is the SDRAM still affected.
> > >
> > > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > > other changes of the NANDFLASH state do we have after the first
reset
> > > command (some clock maybe turned on)?
> > >
> > > The more I look into that problem the confused I am. I'm very
happy to
> > > get new hints or advices.
> > >
> > > Matthias
> > >
> > >
> > > Report this post
> > >
> > > --- In A...@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 )
line of the Synchronous DRAM will be better. I guess the higher the
frequency the shorter the adjacent traces that can crosstalk (like
antennas with length equal to multiples of the wavelength). On my bad
layout the clock line is running a rather unnecessary long way
adjacent to other traces etc.
Cheers,
Matthias
--- In A...@yahoogroups.com, "Rick Collins"
>
> Changing the clock rate will do little to change crosstalk. Crosstalk
> is caused by a fast edge rate, not the frequency. Just changing the
> clock frequency does little. You should be able to inspect the layout
> to find potential crosstalk problems. Traces on adjacent layers
> running above one another is the only configuration that contributes
> significantly to crosstalk. Do you have any traces that run parallel
> more than a couple of inches on adjacent layers?
>
> Rick
>
> --- In A...@yahoogroups.com, "matthiasbuhl"
> >
> > I also reduced the Master CLock from 48MHz to 24MHz to see if
> > crosstalk is the cause (if it is bad layout) but there was no effect.
> >
> > Matthias
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl"
> > >
> > > Hello,
> > >
> > > I checked application notes for the SDRAM layout and found that my
> > > layout is far from being perfect. I really have to clean up my
board,
> > > but I'm not quite sure is the bad wiring is really the cause for my
> > > problems.
> > >
> > > Further investigations came up with this: As long as I don't
send any
> > > command to the NANDFLASH the SDRAM is working fine!! As soon as
I send
> > > the first command to the NANDFLASH (which is a reset command in the
> > > initialization) the SDRAM is showing the above stated behavior (some
> > > bytes are wrong in the writing process). I don't understand
this. The
> > > NANDFLASH and SDRAM are both using the lower data bus (D0..7). But
> > > after working on the NANDFLASH the /CE line of the NANDFLASH
goes HIGH
> > > and the input pins of the NANDFLASH should be high-z and therefore
> > > unresponsible. Why is the SDRAM still affected.
> > >
> > > Can I somehow measure if the NANDFLASH pins are back to high-z? What
> > > other changes of the NANDFLASH state do we have after the first
reset
> > > command (some clock maybe turned on)?
> > >
> > > The more I look into that problem the confused I am. I'm very
happy to
> > > get new hints or advices.
> > >
> > > Matthias
> > >
> > >
> > > Report this post
> > >
> > > --- In A...@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 )
Re: AT91SAM7SE512 and K4S561632J SDRAM Problems - Rick Collins - Dec 9 23:35:08 2008
The cause of crosstalk is not related to antenna length or frequency.
The cause of crosstalk is capacitive coupling between adjacent
traces. That is why the traces have to be on adjacent layers running
directly next to one another. Then the surface area of the traces
forming the capacitor result in maximizing the capacitance between
the. If the traces are on the same layer, the area of the facing
surfaces is much smaller due to the minimal thickness of the traces.
Radiated EMI *is* related to antenna effects which can be related to
the frequency. But the edge rate determines the harmonic content.
Often the harmonics are radiated more strongly than the fundamental,
so a faster edge rate can result in a higher harmonic content which
increases the EMI.
It has been awhile since I have studied this, so I may not have the
details exactly right, but the over all concept is correct.
Rick
--- In A...@yahoogroups.com, "matthiasbuhl" wrote:
>
> Maybe you are right but I thought a lower clock frequency of the CLK
> line of the Synchronous DRAM will be better. I guess the higher the
> frequency the shorter the adjacent traces that can crosstalk (like
> antennas with length equal to multiples of the wavelength). On my bad
> layout the clock line is running a rather unnecessary long way
> adjacent to other traces etc.
>
> Cheers,
> Matthias
> --- In A...@yahoogroups.com, "Rick Collins" wrote:
> >
> > Changing the clock rate will do little to change crosstalk. Crosstalk
> > is caused by a fast edge rate, not the frequency. Just changing the
> > clock frequency does little. You should be able to inspect the layout
> > to find potential crosstalk problems. Traces on adjacent layers
> > running above one another is the only configuration that contributes
> > significantly to crosstalk. Do you have any traces that run parallel
> > more than a couple of inches on adjacent layers?
> >
> > Rick
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl" wrote:
> > >
> > > I also reduced the Master CLock from 48MHz to 24MHz to see if
> > > crosstalk is the cause (if it is bad layout) but there was no
effect.
> > >
> > > Matthias
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
The cause of crosstalk is capacitive coupling between adjacent
traces. That is why the traces have to be on adjacent layers running
directly next to one another. Then the surface area of the traces
forming the capacitor result in maximizing the capacitance between
the. If the traces are on the same layer, the area of the facing
surfaces is much smaller due to the minimal thickness of the traces.
Radiated EMI *is* related to antenna effects which can be related to
the frequency. But the edge rate determines the harmonic content.
Often the harmonics are radiated more strongly than the fundamental,
so a faster edge rate can result in a higher harmonic content which
increases the EMI.
It has been awhile since I have studied this, so I may not have the
details exactly right, but the over all concept is correct.
Rick
--- In A...@yahoogroups.com, "matthiasbuhl"
>
> Maybe you are right but I thought a lower clock frequency of the CLK
> line of the Synchronous DRAM will be better. I guess the higher the
> frequency the shorter the adjacent traces that can crosstalk (like
> antennas with length equal to multiples of the wavelength). On my bad
> layout the clock line is running a rather unnecessary long way
> adjacent to other traces etc.
>
> Cheers,
> Matthias
> --- In A...@yahoogroups.com, "Rick Collins"
> >
> > Changing the clock rate will do little to change crosstalk. Crosstalk
> > is caused by a fast edge rate, not the frequency. Just changing the
> > clock frequency does little. You should be able to inspect the layout
> > to find potential crosstalk problems. Traces on adjacent layers
> > running above one another is the only configuration that contributes
> > significantly to crosstalk. Do you have any traces that run parallel
> > more than a couple of inches on adjacent layers?
> >
> > Rick
> >
> > --- In A...@yahoogroups.com, "matthiasbuhl"
> > >
> > > I also reduced the Master CLock from 48MHz to 24MHz to see if
> > > crosstalk is the cause (if it is bad layout) but there was no
effect.
> > >
> > > Matthias
------------------------------------
______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )