MCF5485 SDRAM controller failures at low temperatures

[tstan]

I have a design that uses three independent MCF5485's, each with a 32MBx32 SDR SDRAM part connected.  The board was designed to work at temperatures down to -40C and in our production test about 30% of the boards have SDRAM failures with at least one of the processors.

The problem manifests itself in a couple of ways but is often associated with a movel instruction to the SDRAM.  When the failure occurs no exceptions are generated.  The debug port just dies and we are unable to view the stack contents so we have almost no information about why the failure occurred.  The temperature limit varies somewhat from board to board, but most of the boards fail at temperatures between -20C and -30C.

My software engineers and I have been through the configuration many times and do not believe it is config related.  I have included the initialization script below.

;// SDRAM Initialization
;// SDRAMDS - 8mA drive strength
data.set sd:0xf0000004 %long 0x000002A2
;//CS0CFG - Enable CS0 at 0x00 address CS Size of 32MB
data.set sd:0xf0000020 %long 0x10000018
;//SDCFG1
;data.set sd:0xf0000108 %long 0xC2311600
data.set  sd:0xf0000108 %long 0xC2311700
;//SDCFG2
data.set sd:0xf000010C %long 0x88C70000
;//SDCR
data.set sd:0xf0000104 %long 0xC04A0002
;//Two refresh cycles are required before the load mode register command
;//SDCR
data.set sd:0xf0000104 %long 0x504A0004
;//SDCR
data.set sd:0xf0000104 %long 0x504A0004
;//SDCR
data.set sd:0xf0000104 %long 0xD04A0000
;//SDMR set BANKAD bits
data.set sd:0xf0000100 %long 0x00CD0000
;//enable automatic refreshing
;//SDCR
data.set sd:0xf0000104 %long 0x504A0000

We have seen this with three different vendors of SDRAM parts, ISSI, Winbond and Micron and while we have had quality problem in the past with these parts, I am ready to rule out the SDRAM part as the problem.

Has anyone out there seen similar problems?  Has anyone successfully interfaced an SDR part to the MCF5485 SDRAM controller?

[tstan]

As it turns out, this problem is a function of the SDRDQS rise time.  When the 10-90% rise time on this is greater than 1ns we would get bit errors on burst reads.  When we made some changes that sped up the rise time to about 700ps, the problems at cold temperature went away,  This is not clear in the part literature.

To solve, we set the drive strength to 24ma.  At the termination of the SDRDQS trace (at the four DQS inputs) we added a 100ohm pullup and a 100ohm pulldown resistor.

[plattro]

Hi tstan

We had some similar challenges wiht the MCF5475 (266MHz) interface to SDR SDRAM.

We found the routing of the SDRDQS signal is very important, and the series termination needs to be fine-tuned to achieve the nicest shape clock edges, else the SDRAM controller hangs. We have the XLB bus monitor enabled, so it detected the hang.

We experimented with the drive strength, in our design the 'default' of 16mA was fine.

We also found that some SDRAMs seem to require a number of random read or write cycles after first initialization of the SDRAM controller, otherwise they sometimes act flaky at the beginning. This seems like a thing from the "Old days" of 16Kbit DRAMS in 16-pin DIP packages, and isn't described in the literature for our SDRAMS, but did the trick for us.

[TomE]

> We also found that some SDRAMs seem to require a number of random read or write cycles after first initialization

We had exactly the same with SDRAM on an MCF5329 at 80MHz. Without some read and write cycles after initialisation the first reads would sometimes return garbage data.

Tom