Mayank Kaushik escreveu:
>>That two layer PCB would make me nervous...
> 
> why? we placed the sdram right next to the microcontroller, the
> dataflash is working fine. The power supply for the board is external.
> Everything works, except the sdram..and i dont know yet if its a
> hardware error or a software error :-( i repeat, is there any program
> thru which i can very the working of the sdram beyond doubt? til now,
> all ive been doing to check the sdram is writing a byte  on the sdram
> thru a unsigned char *ptr, and reading it out thru another unsigned
> char *ptr2.
> 
> Regards,
> Mayank
> 

Ground bounce would be my first guess. It could really be more visible 
in the SDRAM interface due to its speed, since the FLASH is much slower.
In 2-layer designs I've experienced ground bounce leading to errors in 
speeds as low ad 1MHz. A ground plane helps a lot, and even in 2-layer 
boards you can have something similar if you use all the free board area 
with a ground copper pour (I don't know whether you've done it in your 
board).

Ricardo

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> skrev i meddelandet 
news:1115279337.417595.201180@f14g2000cwb.googlegroups.com...
>> That two layer PCB would make me nervous...
> why? we placed the sdram right next to the microcontroller, the
> dataflash is working fine. The power supply for the board is external.
> Everything works, except the sdram..

...

I was thinking of possible EMC problems.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB

> That two layer PCB would make me nervous...
why? we placed the sdram right next to the microcontroller, the
dataflash is working fine. The power supply for the board is external.
Everything works, except the sdram..and i dont know yet if its a
hardware error or a software error :-( i repeat, is there any program
thru which i can very the working of the sdram beyond doubt? til now,
all ive been doing to check the sdram is writing a byte  on the sdram
thru a unsigned char *ptr, and reading it out thru another unsigned
char *ptr2.

Regards,
Mayank

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> skrev i meddelandet 
news:1115135210.802848.203810@f14g2000cwb.googlegroups.com...
> Hi everyone,
>
> ive been trying to interface a 16MB SDRAM (MT84LC8M16A2, 128Mbit,
> 2x16x4)with an AT91RM9200 on my custom board. The SDRAM and the uC are
> placed close to each other on the 2-layer PCB (which me and my friend
> designed).
>


That two layer PCB would make me nervous...

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

Mike Wolfram wrote:

> you will also need to know, how your SDRAM is organized, e.g. 12x8 or
12x9.
> 16 MB module is just 12
> rows and 8 columns, the 32 MB would be 12x9.

I have that covered, i know that my chip is 12x9 (MT84LC8M16A2TG), i
have configured it properly..the chip in question is a 4096rows x
512columns x 4banks x 16bits = 128Mbits = 16MB

Thanks,
-Mayank

Hi,

you will also need to know, how your SDRAM is organized, e.g. 12x8 or 12x9.
We have run into the same problem last year. We designed our on board and
the board making company installed 16 MByte SDRAM instead of 32 MBytes. So
we had to configure in the loader.bin, that the 16 MB module is just 12
rows and 8 columns, the 32 MB would be 12x9.

--
Mike Wolfram

Hello, everyone..

Thanks for your replies.
Yes, i had not recompiled loader.bin for 16-bit operation.

But i got another application from the AT91-CDROM, called
BasicDataFlash. It takes in the file to be loaded from the
hyperterminal, and stores it in SDRAM, where it modifies the 6th ARM
vector, and stores it in DataFlash, so that next time the uC can boot
off the DataFlash.

I changed the value of the bus width to 16-bit in this application. But
here, too i am getting the same error...the transmission through
hyper-terminal aborts with "too many errors" ..

what could be going wrong now? also, is there some sure-shot way of
verifying that the sdram is 100% ok?

thanx in anticipation,
Mayank

Mayank Kaushik wrote:

> But no..im trying to load u-boot into the SDRAM. I found this
> application on the AT91-CDROM -> i first send a file called
> "loader.bin" into the SRAM (via HyperTerminal) using the default ROM
> bootloader of the AT91Rm9200 ..this "loader.bin" file re-inits the
> xmodem service on the uC ( i can see CCCCCC.. again), and then im
> supposed to send "u-boot.bin". (This u-boot.bin is transferred directly
> to the SDRAM)
> 
> "loader.bin" goes in fine, but when i try sending "u-boot.bin", the
> Hyperterminal file transfer exits with a "too many errors" message
> after sending one or two packets.

Did you recompile the loader.bin from the CD-ROM? It is made for 32 MB
SDRAM, so you need to configure the SDRAM there and recompile it.

--
Mike Wolfram

"Mayank Kaushik" <prehistorictoad2k@yahoo.com> wrote in message
news:1115135210.802848.203810@f14g2000cwb.googlegroups.com...

>
> "loader.bin" goes in fine, but when i try sending "u-boot.bin", the
> Hyperterminal file transfer exits with a "too many errors" message
> after sending one or two packets.
>
> I think the CRC checking of the embedded xmodem service is failing, and
> thats whats causing the errors. Which casts doubts on the SDRAM
> again..any ideas?
>

I suspect that neither "loader.bin" nor "u-boot.bin" configures the SDRAM
controller
for 16-bit operation. "loader.bin" loads successfully / correctly because it
gets loaded
into the integrated 32-bit SRAM. It attempts, unsuccessfully, to load
"u-boot.bin" into
"32-bit memory" which explains the errors.

> One thing more..how does the uC know that theres only one 16MB SDRAM
> chip connected, instead of two as on the AT91Rm9200-DK? How does a
> 32-bit number get stored on the SDRAM when the data bus width is only
> 16-bits? The only change ive made to the SDRAM initialisation software
> available for the At91rm9200-Dk is configuring the data-bus to be
> 16-bit (instead of 32-bit as on the -DK)
>

You configure the SDRAM controller by writing certain values into its
registers.
(as you say you've done!)
A 32-bit number is stored by means of two 16-bit cycles.

--
Cecil

Hi everyone,

ive been trying to interface a 16MB SDRAM (MT84LC8M16A2, 128Mbit,
2x16x4)with an AT91RM9200 on my custom board. The SDRAM and the uC are
placed close to each other on the 2-layer PCB (which me and my friend
designed).

I wrote a small SDRAM test program that sends a unique *byte* to each
location of the SDRAM, and then reads it back..it ran without any
errors, all values matched. so i concluded that the sdram was working
fine.

But no..im trying to load u-boot into the SDRAM. I found this
application on the AT91-CDROM -> i first send a file called
"loader.bin" into the SRAM (via HyperTerminal) using the default ROM
bootloader of the AT91Rm9200 ..this "loader.bin" file re-inits the
xmodem service on the uC ( i can see CCCCCC.. again), and then im
supposed to send "u-boot.bin". (This u-boot.bin is transferred directly
to the SDRAM)

"loader.bin" goes in fine, but when i try sending "u-boot.bin", the
Hyperterminal file transfer exits with a "too many errors" message
after sending one or two packets.

I think the CRC checking of the embedded xmodem service is failing, and
thats whats causing the errors. Which casts doubts on the SDRAM
again..any ideas?

One thing more..how does the uC know that theres only one 16MB SDRAM
chip connected, instead of two as on the AT91Rm9200-DK? How does a
32-bit number get stored on the SDRAM when the data bus width is only
16-bits? The only change ive made to the SDRAM initialisation software
available for the At91rm9200-Dk is configuring the data-bus to be
16-bit (instead of 32-bit as on the -DK)

The following is the list of connections between the SDRAM and the uC,
please tell me if u think theyr ok:

16-bit data bus (configured by writing 0x10 in the SDRAM controller`s
mode register on the uC)

SDRAMC pins -----> Pins on the SDRAM
----------- -----------------
A2-A11-----> A0-A9
SDA10-----> A10
A16-A17(BA0-BA1)-----> BA0-BA1
SDCKE-----> CKE
SDCK-----> CLK
A0/NBS0-----> DQML
NBS1-----> DQMH
CAS-----> -CAS
RAS-----> -RAS 
SDWE-----> -WE 
SDCS-----> -CS 
D0-D15-----> DQ0-DQ15