AnsweredAssumed Answered

SDRAM communication problems with MCF5484

Question asked by Alexis Vander Biest on Jul 14, 2009
Latest reply on Aug 6, 2009 by Alexis Vander Biest

Hello,

 

First of all, sorry for the length of the message but the problem is quite complex and I need to explain it in details to make it clear.

 

I'm currently trying to interface a MCP5484 with a SDRAM and I have some problems despite my numerous attempts to get it working properly and I could probably use some help from people who have some experience in this kind of design

 

The context is the following :

I use two 16 bits 46V16M16 -6T DDR memories for a total of 64 Mbytes which are similar to the memories embedded on the 5484 Lite kit development board (the only difference is the speed grade -75, the memory I use is faster). The schematics of my design mimics the development board regarding the SDRAM and the CPU part (no need to reinvent the wheel here) and the layout was performed with respect to all the considerations of path length, decoupling, etc.

 

I use a small software called bdmctrl to send bdm commands to the ColdFire and wrote a small script to get all the registers of the SDRAM controller initialized based on the operation mode described in the datasheet of the DDR and MCF5484.

 

First problem :

In some way, the SDRAM seems to respond to read and write requests but I still have two problems which prevent me from using it normally. Indeed there is a systematic misalignment of the data written inside the memory.

 

To explain it further, if I try to write the following in the memory (at each address I'm writing the lower byte of the address), I should read :

@0x1000 0000 : 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F

@0x1000 0010 : 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F

while I'm reading the following :

@0x1000 0000 : 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17

@0x1000 0010 : 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07

 

The pattern is simple and seems to be similar through the whole memory depth (as far as I tested) : bits 4 and 3 of the address are modified as followed (data meant to be written at an address containing bit 4 = 0 and bit 3 = 0 is written at the same address where bit 4 = 1 and bit 3 = 1 or in short : 00 =>11 ) :

00 => 11

01 => 00

10 => 01

11 => 10

 

Bits 4 and 3 of the address are translated by the SDRAM controller into bits C2 and C1 of the column address so that this problem seems to be linked to the burst mode. Indeed when I move from Burst Length (or BL) = 8 to Burst Length = 2, the misalignment disappears at the price of a severe performance loss which I cannot tolerate for my application. Trying to guess what the problem is, it's a bit as if the controller and/or the SDRAM mixed things up regarding the interleaved/sequential nature of the burst mode. However the SDRAM controller of the MCF5484 only supports sequential mode and the memory is also configured as sequential (bit 3 of the mode register). I tried interleaved mode in BL=8 just in case but data are still misaligned but not in the same way.

 

I'm pretty stuck here because the script I wrote with the very same BDM commands sent to the CPU of the development card does not produce that misalignment of the data even for a BL=8.

 

Second problem :

Among the read data, some of the bits just toggle for no good reason from one reading to another without performing any writing between these consecutive readings. It I try to successively read several times the same memory region, some of the bits may toggle (with no particular pattern and in what seems to be a random order) but then return to the value they should have after the following reading. Much stranger, some bytes suddenly toggle to 0xFF at random locations in the memory: this is something I cannot understand (with my limited knowledge of the internal SDRAM working) because there 32 bit data port is based on two separate chips of 16 bits operating in parallel. If there was a problem of timing, why would a single byte out of the 16 bits of the memory port have an incorrect 0xFF value while the other byte has the correct value ? Again this problem doesn't appear on the development board

 

This test was done filling the memory with the previously described content, the misalignment of the data being of course present. More than likely, these are two independent problems.

 

I tested a lot of things to get the design working but none of those succeeded :

  • Changing the RDLAT from 0x05 to 0x08 as suggested from one of the previous post about SDRAM issues (I use a CASL = 2.5 with a clock of 100 MHz)

  • Relaxing all the timings other than RDLAT and WLAT

  • Disassembling the code from Debug, the bootloader provided with the development board to make sure all the registers are written with the same values in my own script and there are no differences with the values I calculated based on the timing of the DDR

  • Verifying the layout, the schematics and the PCB as far as I could (the design of the PCB was outsourced, I only contributed to some of its supervision) but we have almost no test points and due to the inner layered strip-lined routes, the packages of the CPU (BGA) and the SDRAM (TSOP) , it's almost impossible to measure anything.

  • Sacrificing young SDRAM memories to the EDA gods but that didn't work either

 

Any help would be appreciated

Thanks a lot,

Alexis

 

P.S. : Here is the code I used

 


open /dev/bdmcfg0
reset
sleep 100

# MBAR @0x8000 000
write-ctrl 0x0C0F 0x80000000


# SDRAM Initialization

# SDRAMDS : all I/O are set in SSTL_2 Class II 15 mA compliant mode
write 0x80000004 0x000002AA 4

# SDCS0 : place 64 Mbytes starting at base address 0x10000000
write 0x80000020 0x10000019 4

# SDCFG1 : timing considerations for the memory
write 0x80000108 0x73711630 4

# SDCFG2 : timing considerations for the memory
write 0x8000010C 0x46370000 4

# Issue PALL
# SDCR
write 0x80000104 0xE10B0002 4

# Initialize extended mode register
# SDMR : Enable DLL and launch LEMR command
write 0x80000100 0x40010000 4

# Initialize mode register
# SDMR : Reset DLL and launch LMR command
write 0x80000100 0x058D0000 4

# Wait a bit for the DLL to start (minimum 200 clock cycles at 100 MHz => 2µs) => sleeping for 1 ms should be enough
sleep 1

# Issue PALL for the second time
# SDCR
write 0x80000104 0xE10B0002 4

# Perform two refresh cycles
# SDCR : first refresh
write 0x80000104 0xE10B0004 4
# SDCR : second refresh
write 0x80000104 0xE10B0004 4

# Write to register mode for normal operation
# SDMR
write 0x80000100 0x018D0000 4

#Write to SDCR to lock SDMR
write 0x80000104 0x610B0000 4

#Write to SDCR to enable the auto-refresh and enable all DQS
write 0x80000104 0x710B0F00 4

 

Message Edited by AlexisVDB on 2009-07-14 01:20 PM
Message Edited by JWW on 2009-08-09 12:04 PM

Outcomes