ColdfireV2, Reset Problems (PLL)

[thz]

For two years now we have a problem with hardware-reset on Coldfire MCF5234. A certain percentage of the produced

Boards won't come out of reset. Some show the problem only sporadically, others persistently.

Ringing the support lines via our distributor didn't show up any solution. The answer always was, there is no problem on

coldfire, it must be on your board. We have dumped a lot of boards...  Also beginning to look around for other architectures.

Now, I got a updated chip errata sheet, and look there is a problem: SECF131 and SECF163, both related to the PLL not starting cleanly, so processor won't come out of reset. Apparently it's a problem on other processors of the CF-V2 also.

As this means for us a redesign of the boards, I have to try to get as much info possible about the problem and

possible workarounds.

My question now is:   how can I proof which one is the problem. The workaround for SECF131 seems to be relatively simple to realize. The workaround for SECF163 is quiet a bit more complicated. We are using normal PLL mode with external reference clock.

• Are there others who have the same problem?
• Is SECF131 and SECF163 the same problem, with SECF131 related only to normal PLL/external clock?
• Anybody tried the workarounds successfully?
• SECF163 WA seems to be critical in timing, is it? Or could it be done combining RESET-input with a bit of glue logic?
• Exists there a application note or similar for this problem?

thx in advance for any info

Thomas

[must]

   I have a similar problem. I'm using coldfire v1 MCF51JM32 and when press power on the processor isn't work  I don't have the possibility to load the program and when I was looking on the reset pin I observed that the pin is change the value whit a frequency equal to the internal osc frequency.

[TomE]

> Are there others who have the same problem?

We do not have this problem in spite of SECF131 unconditionally stating "PLL Does Not Lock in Normal PLL Mode with External Clock Reference". I asked Freescale this through our Distributor and received the clear response:

] SECF131 deals with incorrect sampling of the clkmod pins. SEC163 deals
] with an internal race condition. For both erratas, there are several
] variables that determine the likelihood of seeing the failure.
] Among these variables is temperature, voltage, power sequencing,
] and process.

> SECF163 WA seems to be critical in timing, is it? Or could it be done

> combining RESET-input with a bit of glue logic?

SECF163 Workaround 2 looks to me to be as simple as connecting CLKMOD0 to /RESET via an inverter. That assumes that /RESET is being driven by a power-on-reset chip that has at least 160us of "hold time" driving /RESET low after power-on.

[stzari]

Hi,

we also had this problem.

It occured on 2 out of around 500 boards. The boards went through the test but stopped working after a few days on the field.

We first implemented the SECF131 workaround, but the boards needed a second reset after POR to startup.

We then implemented the second workaround for SECF163 (just an inverter from /reset to clkmod0) and erything was fine.

Stamatis

[TomE]

> For two years now we have a problem

SECF131 was released in September 2008. You have to read the latest Errata yourself. No use relying on your distributor for this.

You have "persistent failure" boards. That's an advantage. You'll know if the fix works on them.

Do you KNOW that the problem you're having matches SECF131 and SECF163? Is RSTOUT remaining asserted on the bad boards?

Have you been able to implement these fixes on "persistent failure" boards and had them work? SECF131 looks simple enough to test fairly easily as long as you can get to CLKMOD1. That's the only "real proof" of the fix you can trust.

We've just had a problem on the MCF5329, but it might happen to other boards as well.

Check my post here called "MCF5329 (& other) locking up on power on with SDR SDRAM".

The symptom if that problem is that the CPU tries to start, but fails as the SDRAM is jamming the bus and corrupting the data it is trying to fetch from the FLASH. It ends up halted after 9-12 bus cycles.

Does your board show a small number of external fetches after reset? Monitor the chip-selects with a CRO or logic analyser.

If the boards do come out of reset (not matching SRCF's above) but don't work, check the data bus. If is tri-state or is something jamming it. That's what we've been seeing.