1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by Mayank Kaushik, May 3, 2005.

  1. 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
     
    Mayank Kaushik, May 3, 2005
    #1
    1. Advertisements

  2. Mayank Kaushik

    Cecil Hill Guest

    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 Hill, May 3, 2005
    #2
    1. Advertisements

  3. Mayank Kaushik

    Mike Wolfram Guest

    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, May 3, 2005
    #3
  4. 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, May 4, 2005
    #4
  5. Mayank Kaushik

    Mike Wolfram Guest

    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, May 4, 2005
    #5
  6. 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
     
    Mayank Kaushik, May 4, 2005
    #6

  7. That two layer PCB would make me nervous...
     
    Ulf Samuelsson, May 4, 2005
    #7
  8. 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, May 5, 2005
    #8
  9. ....

    I was thinking of possible EMC problems.
     
    Ulf Samuelsson, May 5, 2005
    #9
  10. Mayank Kaushik

    Ricardo Guest

    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
     
    Ricardo, May 6, 2005
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.