M5208 Reset problem?

[DaveSt]

We have a design based on:-

MCF5208CVM166 Coldfire, parts are PCF

  Samsung K4S643232H-UC60 3.3v 32bit SDRAM

 Spansion S29GL016A90TFIR20 3.3v 16bit flash on CS0

 RCON is provided via a 74LCX244

 Crystalis 16MHz

 There is an LED on the CS2 pin

  DRAMSEL, RESET and RSTOUT all have 10K resistors to 3v3. 

The method of operation is:-

 (Interrupts are never enabled)

 Operational code is held in FLASH which is executed from Power-on.

 Setup CS2 as a port output pin

 Flash the LED

 Initialise the Cache for FLASH memory

 Set up the SDRAM controller and initialise the SDRAM

 Memory check the SDRAM

 Copy a relocatable section from FLASH into SDRAM.

 Jump to the relocated code in SDRAM

 Set the Cache for SDRAM memory

 Go into a tight loop (will run from Cache) 

If we force a reset, either an external RESET, a SOFTWARE reset or allow a WATCHDOG reset, in the above state, then everything works fine and the board reboots successfully every time.

If however the Cache is never enabled or disabled before the tight loop so that the instructions are fetched from SDRAM then occasionally the processor will hang after the reset, the board can only be recovered by using a complete power cycle.  

We have an external device generation a RESET every 3 seconds and the failure will occur sometimes as often and after the second or third reset but it may take as long as 5 minute.

Inspection shows the RSTOUT goes low for around 1mS and then high after any of the reset conditions during this time the configuration can be seen on the data bus bits 1-7 and 9. The PLL appears to be locked (as RSTOUT goes high), we have tried removing the CORE voltage from the Coldfire but it did not restart the processor. We have tried a LIMP mode start-up followed by configuring the PLL in software but this had not effect. 

We have tried doing a RESET before the SDRAM is initialised and again this works every time.

In essence the processor never really seems to actually start running. 

Occasionally following the reset the SDRAM will get hot (like in a latch-up situation). This never happens from power on and does not happen every time from the forced reset condition.

The board runs perfectly following a power off-on cycle every time.

Once running the board has no problems what so every with as long as a reset in not carried out. Our full application is completely stable and after quite a few weeks of testing we are very happy with the stability of the whole design.  

This really was the last stage of our design i.e. to implement a Watchdog/external reset providing recovery in the event of an unexpected failure.

We have a lot more information and desperately need to resolve this issue.  

We have tried the 5208EVB with a variation of our code and could not reproduce the situation, but this is DDR based with split bus and so is quite a different design.

Best Regards

Dave

[DaveSt]

David

Sorry, a slight typo'

"(2 & 3)" should read "(b & c)"

"(3 & 4)" should read "(c & d)"

Regards

Dave

[DavidS]

Hi Dave,
A couple independent questions:
1) With the setup the fails would you instead of asserting RESET, have a DMA TImer routine set the RCR[SOFTRST] to cause a software reset instead of the hardware reset?

2) To help determine what is going on with the DRAM, would you please try running the loop code from internal SRAM?

3) When you are asserting the RESET how long do you assert it?

4) What is the time from RESET negating to RESET_OUT negates?

5) Try implementing workaround #2 in the device errata:
http://www.freescale.com/files/32bit/doc/errata/MCF5208DE.pdf
It doesn't directly apply but can't hurt :smileywink:

Regards,
DavidS

Message Edited by DavidS on 04-08-2006 10:35 AM

Message Edited by DavidS on 04-08-2006 10:50 AM

Message Edited by DavidS on 04-08-2006 11:01 AM

[DaveSt]

David

1) We have already tried a software reset, setting bit SOFTRST of the RCR in the mainline code it had no effect. We have also tried a WATCHODOG triggered reset this also had no effect. Is there any mileage in using a DMA timer triggered reset? Please let me know.

2) I will try to get this change made and let you know the result. Do you want the code to run from SRAM accessing variables in SDRAM, or, code execution and variables in SRAM? Please let me know.

3) When we use EXTERNAL RESET it is asserted for 18.5uS. But the problem occurs with any of the resets sources we have tested including SOFTRST and WATCHDOG and these still have the problem.

4) RSTOUT goes low between 66 and 78uS after RESET is asserted, I assume this variation is due to the time that the RESET line is sampled 

5) We have already tried this last Thursday and it had no effect but I will double check just to make sure as it was very late following a long day working on the problem. FYI we could not find any documentation on the register at 0xFC0A8080, is it a non-user register or could there be a mistake in the Errata?

We had the boards running on test over the weekend, over 20,000 automated power on/off cycles were carried out. Power to the boards was applied and removed using a relay under control of our test software. Following each power on we verified a DHCP address allocation, then carried out a short UDP transmission followed by an async. transmission and reception. Each cycle was approximately 10 seconds and every one worked perfectly i.e. there were no power on cycles that did not perform the above communications. This proved to us that POWER-ON reset really does always works. 

Best regards

Dave

[DavidS]

Hi DaveS,
Sorry for delay. I was traveling yesterday.
Answers to your questions:
1) Don't think using hte DMA timers will help.
2) Run code and data for loop in internal RAM.
5) The workaround is writing to an un-documented register to force the SDRAM and internal clocks to re-sync.

Do yu have logic analizer? If yes, would you capture the DATA[15:0] for pass and fail conditions?
I'd lso like you to be able to boot with RCON pulled high but with your configuration of 16-bit flash and 32-bit SDRAM I don't see how you can unless your system if very harware configerable. Is it? The reason I'd like to see that is to take the rset conditions on the external pins out f the equation. My gut feeling is the SDRAM is driving the DATA lines o non-desired state
Please let me know what values you are driving on Data lines during reset please. Especially D[8] and D[0].
Regards,
DavidS

Message Edited by DavidS on 04-11-2006 12:10 PM

[DaveSt]

David/Mark

I have had a number of discussion with Mark from Future.

1. The Future Quebec board has the same problem when running our test software so it confirmed that it was not a layout problem.

2. I applied the two modifications (10K pull-up on SD_CS and RCON high on D0 and D8) that were suggested by Mark and neither and both cured the problem.

3. I can now confirm that the SDRAM is competing on the DATABUS during the RSTOUT (driving against the RCON buffers) and during CS0 (driving against the FLASH).

It seems to me that there is a fundamental floor in the SDRAM controller/SDRAM implementation not forcing the SDRAM into tri-state during a reset, could this be due to an incomplete BURST cycle.

This also explains why 5208CVB works since it uses DD RSDRAM the DDR SDRAM is on D16-31and the RCON+FLASH are on D0-D15.

Where do I go from here??

Regards

Dave

[DavidS]

Hi DaveS,
Ok...I really thought that if the D[0] and D[8] were actively driven they would defeat the SDRAM but on hindsite whenever anything is fighting...the one that is pulling to ground wins.
If we assume that to be the case....I need to chew on it and chat with several other engineers from the factory. I agree that with 32-bit SDRAM this is the issue and with 16-bit SDRAM or using the DDR which is 16-bit there is not an issue.
Can you send me your test code? I have a Future board that I can run it on.
The only other thing that I can think of would be to have a series resistor on data lines such that when a reset is driven on the D[0] and D[8] lines that the it can out drive the SDRAM.
What you've given me so far is really good information that I can present to our silicon test team and others. I feel that this may be an errata we need to either figure out a workaround or do a silicon fix. Note that is a personal observation and not a confirmed one for those that are following this saga.
Regards,
DavidS

[DaveSt]

David

I suspect that the problem goes deeper that just during the RCON read.

It looks to me that the SDRAM is also competing with the Flash memory after RSTOUT goes high.

I have not used SDRAM in a design before but from what I can read in datasheets it is not possible to simply raise CS to tri-state the outputs, CS is only used internally to select the command decoder.

Seems to me that my RESET occurs either part way through a read burst or part way through a read cycle and the SDRAM (which has an internal state engine) still thinks it is selected so it is totally unaware of the RESET sequence. I believe that the COLDFIRE should hold off accepting the reset until completion of the read (burst) cycle so that the SDRAM is in an idle state when the RESET is actioned or the COLDFIRE must terminate the SDRAM read(burst) cycle to force the SDRAM into an idle state before actioning the RESET. From what I have read is seems to me that SDRAM devices should really have an asynchronous RESET input.

Since once the problem occurs the SDRAM can get very hot and it is not possible to recover to a functional state, I believe that any RESET source, other than power on, is NOT USABLE ON THE MCF5208 (and maybe other variants) if 32bit SDRAM is used.

I have an additional processor (Silicon Labs. 8051) on my board which drives RESET into the COLDFIRE, the 3.3V power supply is provided externally so I do not have a regulator. I think that the only practical solution open to me is to split the power plane, power the 8051 directly from the input and use a low Rds FET to switch the power to the COLDFIRE subsystem (Process, Flash, SDRAM, RCON buffers and Ethernet PHY). This should allow me to reliably reset the whole lot by cycling COLDFIRE subsystem power under a fault condition. 

Best Regards, Dave

[macl]

I can't say I know too much about it, but I thought I thought this thread looked similar to a MCF5208 errata that has been fixed in later versions of the part.

7 Potential boot failure when using 32-bit wide SDRAM

7.1 Description

If the SD_CKE signal to the SDRAM deasserts while one or more banks are active, then the SDRAM enters a “clock suspend” state. If the SDRAM was driving the data lines before entering the clock suspend state, then the buffers will continue to drive. During a reset, the processor will deassert SD_CKE without any graceful stop period to ensure that the SDRAM banks are all in an IDLE state. In some cases the SDRAM could be driving the data bus during and immediately after reset. This can lead to possible bus contention while latching reset configuration (RCON) values and/or while reading boot code from flash, and thereby cause the processor to enter an undefined state.

7.2 Workaround

• Use a split bus mode configuration with either DDR SDRAM or SDR SDRAM. This creates a dedicated 16-bit port for the SDRAM on D[31:16]. In this configuration the SDRAM doesn’t share data lines with other devices so bus contention is not an issue.

• Additional workarounds TBD. We are investigating workarounds that can be used for 32-bit wide SDRAM configurations.

7.3 Status

Fixed starting with 2M28B mask set.

[DaveSt]

David

Sorry

4) should have been "66 and78nS" not uS.

Regards

Dave

[UK_CF_FAE]

Hi Dave,

Your memory access timings with/without the error condition are consistent with my expectations. 750ns for the working system is 1/166MHz * 2 * 63 - the default CS0 wait state settings.

However in your failed case, the timing is 12 ns - ie 1/166MHz * 2 - this is going to be too fast for most flash memories. It seems that the default settings for the CSCR0 [WS]  bits are incorrect.

I'll look into this some more.

Mark

[DaveSt]

Dave

Thanks for the complement!

1. Yes. PSTCLK is clocking at the core frequency of 166MHz.

2. The loop that was executing when the failed RESET took place is a simple bit of C code as follows:-

//Interrupts disabled and SR=0x2700. 

printf("\n\nStarting");

while (TRUE)

 {

 UINT32 Count;

 for (Count=0; Count<100000; Count++)

   {

   *((VUINT32*)0x41400000)=*((VUINT32*)0x40400000);

   *((VUINT32*)0x40400001)=*((VUINT32*)0x41400001);

   }

 printf(".");

 for (Count=0; Count<100000; Count++)

   {

   *((VUINT32*)0x41400000)=*((VUINT32*)0x40400000);

   *((VUINT32*)0x40400001)=*((VUINT32*)0x41400001);

   }

 }

We have tried other variants all cause the same problem. One important point is that we have to turn the cache off to cause the problem; we assume that this is due to the fact that SDRAM access is required to cause the problem. There has been no DMA setup, interrupts have never been enabled and the MAC has not been initialised.

3. Board is currently configured for PLL mode

Under normal operation:-

As RSTOUT goes high CS0 is high

   a. Stays high for around 200nS following the RSTOUT high

   b. goes low for around  750nS

   c. then goes high for 110nS

   b (2 & 3) are repeated for a number of cycles is step with program execution

Under fault conditions:-

           a. CS0 goes low about 10nS after RSTOUT goes high

           b. It stays low for only around 60nS

           c. it then goes high for around 60nS

           d. it then goes low for around 12nS

           e (3 & 4) are repeated for a number of cycles

           f. At some point this changes to 12nS high then 12nS low

4. Yes I have RSTOUT connected to both the  –OE’s  of the 74LXC244WM and I can see the configuration on the data lines during RSTOUT low.

Kind regards, Dave

[DavidS]

Hi Dave,

Good detail in your post.  The is very much appreciated.

When processor is hung... do you see PSTCLK clocking at the core frequency?

What is the tight loop you are using?

Are you seeing the CS0 asserting to flash after the RSTOUT goes high (i.e. is reset exception trying to occur)?

Are you using RSTOUT to drive the OE on the 74L?

Regards,

DavidS