MPC5200B DRAM suppurt

[sburck]

I'm working with a company helping them debug their new hardware, which is a board based on a MPC5200B (In the past, I helped them write a bootloader for a 555 based board - this is their first upgrade of it).

We've got everything on the board working except for the DRAM.  There's SRAM on the card which is working, and I've got the board booting, initializing the chip selects for the flash, SRAM, UART, and some other devices, and have the bootloader ported and working.

The DRAM is another story.  They've written to Freescale support for help, so far to no avail.  I thought I'd try here.

The DRAM is two Micron MT46V8M16TG-6T, in parallel, each being 16 bits of 32 bit data in 4 banks on CS0

After lots of playing around, this is the closest CFG file I have for making it work:

writemem.l 0xF0000034 0x00000018 ; SDRAM CS0, 32 MByte physical, logical start @ 0x00000000
writemem.l 0xF0000038 0x00000000 ; SDRAM CS1 - disabled

; init SDRAM controller for DDR 132MHz
sleep 200
writemem.l 0xF0000190 0x00000004 ; SDelay
sleep 100
writemem.l 0xF0000108 0x73733930 ; SDRAM Config 1                         
sleep 100
writemem.l 0xF000010C 0x58870000 ; SDRAM Config 2
sleep 100
writemem.l 0xF0000104 0xF05F0F00 ; SDRAM Control
sleep 100
writemem.l 0xF0000104 0xF05F0F02 ; SDRAM Control
sleep 100
writemem.l 0xF0000100 0x40010000 ; SDRAM Mode
sleep 100
writemem.l 0xF0000100 0x058C0000 ; SDRAM Mode
sleep 100
writemem.l 0xF0000104 0xF05F0F02 ; SDRAM Control
sleep 100
writemem.l 0xF0000104 0xF05F0F04 ; SDRAM Control
sleep 100
writemem.l 0xF0000100 0x018C0000 ; SDRAM Mode
sleep 100
writemem.l 0xF0000104 0x705F0F00 ; SDRAM Control
sleep 100

IncOrmmr    ACFG 0x00002000

----

When we load this, we can access the DRAM, but there are errors.  We have a test, which we run from the SRAM,  that looks like this:

    for(i=DRAM_START;i<DRAM_END;i++)
    {
        DRAM_ptr = (char *)i;
        *DRAM_ptr = (char)0xAA;
        AA = *DRAM_ptr;
        *DRAM_ptr = (char)0x55;
        SS = *DRAM_ptr;
        *DRAM_ptr = (char)0xFF;
        FF = *DRAM_ptr;
        *DRAM_ptr = (char)0x00;
        OO = *DRAM_ptr;
        if ((AA != (char)0xAA) || (SS != (char)0x55) || (FF != (char)0xFF) || (OO != (char)0x0))
        {
             if (errorcount < 100)
                firsterrors[errorcount++] = i;
        }
    }

We get several errors running this test.  If however, we precede the test with:

    for(i=DRAM_START;i<DRAM_END;i++)
    {
        DRAM_ptr = (char *)i;
        *DRAM_ptr = (char)0xFF; // or 00, it doesn't seem to matter
    }

Then there are no errors.  This leads me to believe there is something in the sequence missing which is leaving the RAM in a bad state, which is fixed by enough writing and waiting, or something to that end.

This has been a problem for over two weeks now - if there is anyone who has had a similar experience, it'd be a great help.

[Takko]

Hi sburck,

I hope you solved your problem but still are somewhere around here.

We are haveing the same or similiar issue with our board runnning a MPC5200B. 

We are using one SDRAM (MT48LC16M16A2-75 , 16bit Databus , 66MHZ)

When we connect a debugger (Lauterbach) and are looking at a memory dump of the SDRAM, we see

some bits toogling around. The toogling is only if we read out the memory with 32 bit bursts (2 bits on each DQ per read), not with 16 bit bursts. Also the toggling only happens on the low nibble of the upper 16 bits, but not in every 32 bit Word. (bits marked with x ---0000 xxxx 0000 0000 ).

Looking at the signals with an oszilloscope the slew rate / Tsetup and Thold seems to be ok.

Attached you can find two pictures of the command signbals + one Data Signal DQ8  

 If you have any idea I'd appreciate your input.

Thanks, Daniel 

[sburck]

I was surprised to see this thread still alive - that project was years ago.  The lines for the RAM were the problem - they were OK for the SDRAMs in the original project, but the DDRAM that replaced them were flaky because of ringing.  After redoing the card with shorter lines the problem went away.