> Since this design works with the Micron part and occasionally fails with ISSI,
Don't assume that that difference that you're seeing is the cause of the problems you're having.
If you think there's a problem with the initialisation, you should be able to repeat it. Make the initialisation sequence run twice (or more) and see if the system works after the later sequences.
Concerning the "writing to the mode register" that you're seeing. Does it do this from cold power-up and/or soft reset? We had a problem (detailed as the second one below) where the SDRAM controller generated illegal cycles on cold power-up, but was OK on normal resets.
We've experienced multiple problems with SDRAM startup, in our case on MCF5329.
Most SDRAM on the planet is in PCs and laptops. Their Boots take a long time to start up, and probably don't start using the SDRAM immediately after initialising it. So we found the following was necessary for reliable operation:
/* Do a read from RAM */
/* NOTE! This is a hack until the issue is better understood!
Without this read here, some boards read corrupt values out
of RAM on the first burst read. If the first burst read is
when the code is being executed from RAM then corrupt
instructions are read and an illegal instruction occurs.
*/
That's probably not your problem, but it is worth adding some extra "exercise" of the chips before using them for real.
The second problem was detailed in a post on this forum, which I'll now have to search for ...
MCF5329 (MCF5xxx) + SDR DRAM = lockup, anyone else?
The problem we experienced was that the DDRAM Controller inside the CPU IS NOT INITIALISED with the Reset pin. It seems to wake up in a "random mode" and requires clocks (from the crystal) to be fed into it before it will clock itself out of whatever random state it powered up in to its "normal" state. During that time it can clock illegal commands into the SDRAM. Which can then lock up, jam the bus and do whatever it likes. As long as the power supply to the CPU is below 2.0 to 2.6V the SDRAM controller pins are tri-stated, and you can rely on external pullups or pulldowns (on CK and CKE) to keep the SDRAM chip happy. Then you have to get the EVDD power supply to 3.0V (for the oscillator to start) before it gets to 2.0V (for the pins to come out of tri-state), which is tricky to say the least.
This is compounded with the MCF5329 as the Flash and SDRAM share the same data bus. So when the SDRAM controller send bad signals to the SDRAM, it can then jam the data bus, which prevents the CPU from reading instructions from the Flash, and so it crashes. A recommended fix for this problem is to use the "split data bus" with Flash on one half and RAM on the other, with half the bandwidth available.
I wrote a 41-page report on this problem back in 2010.
You're using a different chip, so its SDRAM controller may not have the same problems.
Here's another instance of the same problem with a different chip from 2007:
https://community.nxp.com/message/26423
The third problem had failures with Micron SDRAM chips, but ISSI ones worked OK. This turned out to be due to the MCF5329's undocumented drive-strength settings. At the default level (which we left it as as the settings weren't listed in the manual, and still aren't) the signals were too "aggressive" and caused overshoot and undershoot. This caused the SDRAMs to lose data. Writing all-zeros to an all-ones address triggered the problem pretty much instantly, with "the number of ones-bits" being the deciding factor. 26 ones didn't fail, but it got progressively worse going from 27 to 32.
MCF5329 with random SDRAM 1k "bit rot" corruptions
I find I've written this sort of response before, so you might like to read these ones:
ColdFire 5329 cache problems.
Troubleshooting DDR2 RAM problems
Does your chip have an undocumented "Duty Cycle Corrector" like the one in the above post had? Turning that off fixed their problem.
Let us know what you find.
Tom
