MCF5482 SDRAM Controller Problem

[Silver]

Recently I encounter a problem of ColdFire microprocessor MCF5482.

I find that when the VCC on the board of MCF5482 drops below 3.2V, the program will run away and the watchdog chip on the board will reset MCF5482.

The program is running in SDR SDRAM when it runs away, so I use a simple program that runs in Flash to test the writing and reading operation of SDRAM under the low-VCC (<3.2V) condition, then I find that the test program frequently halt during the reading operation. And when the program halts, the MCF5482 also does not response to GPT timer interrupt. Sometimes the test program halts for several minutes then continue running, sometimes increase the VCC to 3.3V also make the test program continue running.

I also find that the test program seldom halts if the SDRDQS drive capability is set to 24mA, currently the SDRDQS drive capability is set to 16mA, and other SDRAM controller related signals’ drive capability is set to 8mA. The SDRAM clock is 80MHz.

I have captured the waveforms during reading of SDRAM using Logic Analyzer and I don't find any violation of timing specification.

As below figure shows,

Figure-1 shows that test program runs about 1ms then halts during reading operation on SDRAM.

Figure-2 shows the waveform in details just before test program halts.

Below are my questions:

Does the waveform in above figure violate the timing specification of MCF5482 SDRAM controller timing specification?

What cause my test program halts during reading operation of SDRAM?

What status of MCF5482 is when it halts the test program and does not response to GPT timer interrupt?

Thanks a lot for kindly response!

[TomE]

---

> Silver wrote:

> the test program frequently halt during the reading operation.

When you say "Halt", what do you mean" Is the CPU is a real "halt state" or does your program stop printing on a serial port or something?

> sometimes increase the VCC to 3.3V also make the test program continue running.

Is that a "real continues" or does it restart? I assume you mean it really continues, like it has been solidly stalled.

If you have a watchdog (as stated), then have you disabled it for this test? Otherwise, if it isn't resetting the CPU then something is keeping the watchdog from biting.

> Does the waveform in above figure violate the timing specification

> of MCF5482 SDRAM controller timing specification?

Ditch the analyser and use a good oscilloscope. That may show you signal problems the analyser is hiding. Especially if changing the drive strength changes the result.

I've just had horrible signal problems with SDRAM on the MCF5329.

Are ALL your signals (all control and data and address lines) terminated? If not you may be getting bad overshoots and undershoots. Are you running on a development board or your own one?

> What cause my test program halts during reading operation of SDRAM?

Any number of things. Running code in FLASH as you are doing is a good idea. Running the program in the 32k of internal

SRAM is a better idea. It can't get corrupted if something goes wrong on the external data bus/

Are you running under a debugger? If so, put breakpoints everywhere, on every interrupt. If not,

add interrupt routines for all possible interrupts and have it print out where it is if they trigger.

> What status of MCF5482 is when it halts the test program

> and does not response to GPT timer interrupt?

A real halt. Any interrupt that raises the IPL above your test program. All error interrupts set the IPL to 7. Access to an address that doesn't have anything there to respond. Does that cpu have a "Bus Monitor Timer"? This used to be common in the 68000 days, but these newer parts (53xx) omit this very useful feature.

If the SDRAM controller isn't responding (true lockup) then there's probably no timer to get you out of this. There's none on the MCF5329 that I'm using. It is possible that the controller locks up if it doesn't get DQS returned from the SDRAM. Check that signal (check both or all 4 of them).

[Silver]

Thanks for TomE's valuable suggestions.

1. I am not sure wheather CPU is really in halt state, I just notice that the test program stop printting on a serial port.

2. The test program doesn't restart, it just continues running from where it stops beacause  the serial port output before and after program halt are continous.

3. The watchdog is disabled when test program is running.  I notice that the CPU will be reset when the test program halts If watchdog is not disabled.

4. All the SDRAM related control, data and adress lines are not terminated. I am working on my own board. I do notice there are overshoots and downshoots of SDRDQS signal, but I am not sure they are bad.

5. I have put breakpoints at  all the exception handlers when debugging the test program and I find that the test program never stops at any of these breakpoints. So I think no exception or interrupt happens when the test program halts.

6. I did not notice "Bus Monitor Time" information of this CPU before.  I will check the Reference Manual to find out what it is.

[TomE]

> I do notice there are overshoots and downshoots of SDRDQS

> signal, but I am not sure they are bad.

Try different settings of the SDRAMDS register. Try for the lowest value.

> 6. I did not notice "Bus Monitor Time" information of this CPU before.  I will

> check the Reference Manual to find out what it is.

From the manual:

    17.6.8  Bus Errors
     The MCF548x has no bus monitor.

So it will hang if it isn't seeing the DQS response. it is hanging. Check all FOUR (or TWO) of these signals.

[TomE]

I just wrote:

> It is possible that the controller locks up if it doesn't get DQS returned from the SDRAM.

The MCF4329 Revision History contains the following:

Table 18-1/Page 18-5: In the SD_DQS table entry add the following note:
Note: If a read is attempted from a DDR SDRAM chip select when there is no memory to respond with the
appropriate SD_DQS pulses, the bus cycle hangs. Because there is no high level bus monitor on the device, a
reset is the only way to exit this error condition.

So it is possible the same could happen on your board. There may be a bad solder joint on that line.