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
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.