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
AT91RM9200: Errors in transferring file into SDRAM via HyperTerminal (xmodem protocol)
Started by ●May 3, 2005
Reply by ●May 3, 20052005-05-03
"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
Reply by ●May 3, 20052005-05-03
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
Reply by ●May 4, 20052005-05-04
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 by ●May 4, 20052005-05-04
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 by ●May 4, 20052005-05-04
Mike Wolfram wrote:> you will also need to know, how your SDRAM is organized, e.g. 12x8 or12x9.> 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
Reply by ●May 4, 20052005-05-04
"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
Reply by ●May 5, 20052005-05-05
> 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
Reply by ●May 5, 20052005-05-05
"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
Reply by ●May 6, 20052005-05-06
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