AT91RM9200: Errors in transferring file into SDRAM via HyperTerminal (xmodem protocol)

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

Reply to
Mayank Kaushik
Loading thread data ...

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.

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

Reply to
Cecil Hill

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

Reply to
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

Reply to
Mayank Kaushik

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

Reply to
Mike Wolfram

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

Reply to
Mayank Kaushik

"Mayank Kaushik" skrev i meddelandet news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

That two layer PCB would make me nervous...

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

Reply to
Mayank Kaushik

"Mayank Kaushik" skrev i meddelandet news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

...

I was thinking of possible EMC problems.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Mayank Kaushik escreveu:

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

Reply to
Ricardo

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.