topic Re: MCF5272, 32MB SDRAM and VxWorks. in ColdFire/68K Microcontrollers and Processors

MCF5272, 32MB SDRAM and VxWorks.

japp — Tue, 05 Jan 2010 16:01:58 GMT

Hello, we have designed a board with 32 MB (32x)of SDRAM (2 IC of 16x in parallel) and MCF5272. We have problem when VxWorks is booting and shows an access error or freezes. We have this problem in almost 50 % of the boards.The SDRAM IC's are Micron and we use recommended configuration in MCF5272 datasheet. We have designed another board with the same micro and operating system but SDRAM in x16 configuration without problems.

Anybody has the same problem ?

Thanks in advance.

Joaquin

Re: MCF5272, 32MB SDRAM and VxWorks.

Cactus — Fri, 08 Jan 2010 05:37:47 GMT

Joaquin, Here is a copy of my posting a year ago:

I transfered the 5271 EVB SDRAM (MT48LC4M16A2 x2) to a PCB design using the 5271 QFP.
The driver for the 5271EVB BGA works great, but on the new design
it will only read/write the 1st, 3rd, 5th and 7th 1MByte blocks correctly.
Once CPU A20 (0x00100000) is set high (A20=A10/Precharge), I can't read/write these address's.
The only differance is the QFP and BGA so I suspect there is a mask issue.
The QFP works with a single 8Mbyte device but not two 8Mbyte devices on a 32bit bus.
Any ideas?
Rick Stelzer
rstelzer@rletech.com

I've never had a reply to my similiar issue. We have been stuck with single 8M sdram on a 16 bit bus.

We are looking at increasing the size to 16M and stay on the 16 bit bus but we are nervous over

the driver change.

Rick

Re: MCF5272, 32MB SDRAM and VxWorks.

TomE — Sat, 09 Jan 2010 13:51:51 GMT

japp wrote:
Hello, we have designed a board with 32 MB (32x)of SDRAM (2 IC of 16x in parallel) and MCF5272. We have problem when VxWorks is booting and shows an access error or freezes. We have this problem in almost 50 % of the boards.The SDRAM IC's are Micron and we use recommended configuration in MCF5272 datasheet. We have designed another board with the same micro and operating system but SDRAM in x16 configuration without problems.

Anybody has the same problem ?

Thanks in advance.

Joaquin

Had something similar just this week. MCF5329 with 32-bit-wide SDRAM.

Some of the boards would freeze on boot, get kicked by the watchdog and then work OK after that.

The loader in FLASH copies itself to SDRAM and then jumps to it.

The debugger showed an "illegal instruction trap"on the SECOND instrucxtion fetched from SDRAM.

The debugger showed that of all the data copied from FLASH to SDRAM, 16 32-bit words corresponding to the first cache line fetched by the CPU had their lower 16 bits corrupted.

We were following the SDRAM and Freescale's specs, including the "> 100us wait after clock applied", the two "auto precharge" and the SDRAM chip programming steps.

The fix was to READ aat least one word from the SDRAM before writing to it. We don't know what the problem is, but I'd guess that the SDRAM or SDRAM controller needs "some sort of extra precharge-type operation" after initialisation that writing (and I'd guess the refresh cycles) just doesn't provide.

Does your startup ROM code do a FLASH checksum and an SDRAM test on startup and report the results anywhere?

Re: MCF5272, 32MB SDRAM and VxWorks.

japp — Wed, 13 Jan 2010 19:07:42 GMT

First, thank you both for your help.

Rick, we have another MCF5272 board and we use Micron MT48LC32M16A2 using a 16x bus without problems. I think you can use the same board to test the new configuration. We know MCF5272 have an errata using 32x bus for 256 Mbit but we are using 128 Mbit:

"The SDRAM configuration using two 16-bit-wide, 256-Mbit SDRAM chips does not work. There is an

error in the page mode logic that prevents the SDRAM controller from correctly tracking which pages are currently open when using this configuration. All other SDRAM configurations documented in the 5272 user’s manual work correctly and are unaffected by this errata."

TomE, the problem is similar but I took a look on MCF5329 and I think the SDRAM controllers of MCF5272 and MCF5329 are quite different. We have a first program (called Bootloader) always running right and it is when this program load the operating system VxWorks when the random errors appear on some boards. The operating system uses more resources and SDRAM intensively.

Thank you anyway.

We have SDRAM initialization as described in the manual:

"Each SDRAM requires an initialization sequence before it can be accessed. After power up, the SDRAM

requires a certain time (100 µS) before it can accept the first command of the initialization procedure. After

this time, one PRECHARGE ALL command and eight REFRESH commands are required. After initialization,

an INITIATE LOAD REGISTER SET command is executed, which writes the SDRAM configuration into the

SDRAM device mode register.

SDRAM mode register data is transferred on the address signals, so all SDRAM devices are configured

simultaneously.

Initialization is enabled by setting SDCR[INIT] and performing a dummy write to the SDRAM address

space. The SDRAM controller executes the required PRECHARGE and REFRESH commands and

automatically loads the mode register, which configures the SDRAM as follows:

• SDRAM internal burst is always disabled.

• CAS latency is defined by SDTR[CLT].

SDCR[ACT] is set after initialization."

Re: MCF5272, 32MB SDRAM and VxWorks.

TomE — Sat, 18 Sep 2010 14:52:24 GMT

Did you ever find out what the problem was and find a fix?

We have had two more problems with the SDRAM since my first answer to your post.

The first one was "random corruptions" that showed up on the video every now and then. This was lucky, as without literally SEEING the memory corruptions it would have been a lot harder to track down.

The first one is summarised in my post "MCF5329 with random SDRAM 1k "bit rot" corruptions" here:

https://community.freescale.com/message/66587#66587

That one could be related to your problem. We had a "small" design without bus termination requiring low drive strength from the SDRAM controller. This was the default setup for the MCF5235 in our previous design, but the MCF5329 unexpectedly defaults to "high drive strength" on the SDRAM pins (only, the rest are lower strength) and the spikes and overshoots were too much for the SDRAM chip. Make sure your drive strength setup matches your hardware design - and check ALL the signals with a good oscilloscope too.

Our current SDRAM problem is one that causes intermittent power-on failures, detailed in another post.