Coldfire uControllers failing

[phlp]

Hi all,

I've a few different projects using the MCF51QU family of controllers. I received the uControllers sealed to protect against moisture. I've opened the package and used them as I need them. The package has not been resealed and I have not baked them after they were exposed. It appears that almost all of them are failing. In some cases they will work for minutes and in other cases for hours. One or two has not yet failed. At first I though it was a poor quality PCBs that caused the problems (e.g. float grounds). However in other projects the same happens. I either used a solder iron or reflow soldering to solder. The outcome is the same. Any advice on what could the problem be? Can it be moisture? What's strange though is that the uControllers work for a while and then fail. If the silicon cracks due to internal moisture one would expect them to fail immediately. I've never experienced problems with uControllers not resealed. Can it be a bad batch?

Any advice will be appreciated.

Philip

[phlp · Accepted solution]

Hi all,

It appeared the solder flux expired and caused all the issues!

Regards

Philip

[TomE]

> Can it be moisture?

If the first ones you took out of the sealed package are OK, but the ones used later are failing, then it could be moisture. Otherwise, if the first ones are failing then you've got some other problem.

Also:

> I either used a solder iron or reflow soldering

Reflow is the one that would cause moisture problems Soldering with an iron shouldn't stress the chip anywhere near as much and shouldn't cause moisture related problems.

By not following Freescale's documented handling procedures, you've probably voided the warranty anyway. You should read documents like the following:

http://cache.freescale.com/files/analog/doc/app_note/AN4388.pdf

Your parts are probably MSL3 which means a maximum of 168 hours "out of the bag", after which "the components are required to be baked prior to the assembly process".

I think it is worth including an extract from the above:

Quad Flat Package (QFP)

, Rev. 2.0

Freescale Semiconductor

23

Case Outline Drawing, MCDS and MSL Rating

9.2 Moisture Sensitivity Level

The Moisture Sensitivity Level (MSL) indicates the floor life of the component and its storage conditions and handling

precautions after the original container has been opened.

The permissible time (from opening the moisture barrier bag until the final soldering process) th

at a component can remain outside the moisture barrier bag is a measure of

the sensitivity of the component to ambient humidity.

In many cases, moisture absorption leads to moisture concentrations in the component that are high enough to

damage the package during the reflow process. The expansion of trapped moisture can result in interfacial

separation, known as delamination, of the mold compound from the die or lead-frame, wire bond damage, die

damage, and internal cracks.

In the most severe cases the component will bulge and pop, known as the “popcorn” effect.

Thus it is necessary to dry moisture-sensitive components, seal them in a moisture barrier antistatic bag with a

desiccant and a moisture indicator card which is vacuum sealed according to IPC/JEDEC J-STD-033, and only

remove them immediately prior to assembly to the PCB.

But you may have a completely different problem. Are you boards being exposed to ESD that could be damaging them? Are any of the input pins likely to be exceeding the voltage specifications (voltage outside 0 to 3.3V being presented on any pin)? Is your power supply stable? Might it be "glitching" high on switch-on or switch-off? Are there any inputs that might be forcing the power supply high through some protection diodes?

> The supply to the ADC unit (VDDA and VSSA) is not connected (left floating).

That's outside of the chip specifications. In the Reference Manual, sections 29.2.1 and 29.2.2 it specifically says they have to be connected to VDD and VSS. They're only pinned out so you can connect them via noise filters if you want to.

Try measuring the CURRENT the good and bad CPUs are drawing. If the bad ones are drawing a lot less or a lot more it might be a clue to the problem.

Tom

[phlp]

Thanks, I appreciate your answer Tom.

Reflow is the one that would cause moisture problems

I've used both normal soldering and reflow and get the same result. Also, would damage due to moisture not cause the controller to fail immediately? Mine works for minutes to hours and then fail. For developing prototype I don't have any strict working environment. Once in a blue moon something fails most likely due to not taking the necessary precautions. In this case however it fails consistently.

But you may have a completely different problem. Are you boards being exposed to ESD that could be damaging them? Are any of the input pins likely to be exceeding the voltage specifications (voltage outside 0 to 3.3V being presented on any pin)? Is your power supply stable? Might it be "glitching" high on switch-on or switch-off? Are there any inputs that might be forcing the power supply high through some protection diodes?

Other PCBs work fine from the same supply, so it is doubtful it is the cause of the problem.

> The supply to the ADC unit (VDDA and VSSA) is not connected (left floating).

That's outside of the chip specifications. In the Reference Manual, sections 29.2.1 and 29.2.2 it specifically says they have to be connected to VDD and VSS. They're only pinned out so you can connect them via noise filters if you want to.

Last night I used my last controller from the recent batch I ordered. I soldered (it was not baked) and managed to connect the VSSA and VDDA pins. It again failed. Another PCB from another project using the same controller and running from the same supply kept on working without any issues (its VSSA and VDDA pins were connected to ground and power in the design).

Unfortunately this has now taken too much of my time. I've decided to switch to kinetis controllers (something I wanted to do anyway). I've used many different controllers in the passed, however this is the first major issue that I just can't explain.

Thanks for the advice.

Philip

[TomE]

This doesn't look like a moisture problem. The ones you've hand soldered are failing, so that pretty much says that isn't the problem.

What sort of "failed"?

What is working and what isn't working? I assume they were running the application you loaded onto them, and now they won't. If you say "they've failed" I assume they're not communicating (network, USB, LEDs, serial port, whatever), and you can't get to them with the debugger and can't reprogram them. I'm making a lot of assumptions here, so it would help if you detailed what you've done and what you've checked.

Is the crystal oscillating? Are you using internal or external power-on-reset? Are you using the internal 5V regulator or an external one?

Have you compared the current on good and bad boards? Can you separately measure the CPU current?

What environment are these boards running in? What are they connected to externally? DO you have solid grounds everywhere? Is the power supply guaranteed (with a zener clamp) to never be able to go outside of the specifications? Are all of the external connections likewise clamped or buffered?

A bad batch of chips is possible. The way to test that is to get another batch and see if they behave any differently.

Can you load different (simpler diagnostic) software onto them?

It sounds to me like you may have some floating pins that might be causing problems to the software or hardware. I can't see how they would "destroy the chips", but you haven't proved to me that the chips have "failed" yet. On a more complicated chip I'd suspect a floating BDM pin, but since this chip has the HCS8 single-wire BDM this should be harder to get wrong than on the other chips.

What you you have the BKGD/MS and EZP_MS pins connected to? BKGD has an internal pullup during reset, so if it is floating it should be OK. On the other hand, I've just spent an HOUR reading the manual, and it doesn't look like EZP_MS has a pullup on it, either during reset or at any other time. The port pullup/down settings seem to default to being OFF. So you should probably have a pullup on the EZP_MS pin.

Are you programming the FLASH using EZP or using the Debugger?

Tom

[phlp]

Hi Tom,

OK, I've monitored the current consumption. Current consumption is initially about 10 mA. Over time (sometimes minutes, sometimes hours), the current consumption increases and eventually the uC fails (I assume thermal run away). At the moment only a LED is toggled.

Tried it with a different PC, power supply and different PCB designs using the same processor. Same result.

Regards

Philip

[TomE]

> OK, I've monitored the current consumption. Current consumption is initially about 10 mA.

10mA is the expected current for these chips when running at 25 to 50MHz.

> Over time (sometimes minutes, sometimes hours), the current consumption increases

You've done some tests taking quite a lot of time. Buried in that data may be a clue that would allow others to help you. In summarising the results all the way down to "starts at 10mA and increases" you've left out a lot of interesting stuff. How about some more details? You're not Tweeting to this list after all :-)

To what value of current does it get up to and how does it increase? Does it slowly creep up or does it jump up?

You don't need to let the chips destroy themselves when you see the current increase. You can stop the test there. The Power Supply Current Limit should be set to stop the test and save the chip for you.

I've given other suggestions for measurement in this post and in the Kinetis one. For instance, have you followed the Data Sheet and connected the Analog voltage supply pins? What voltage are you running the chip at - 3.3V or 5V? Are there any voltages higher than VDD being presented to the chip on any pins.

Why not attach your schematic to this thread?

You now know there's an "unexpected" current consumption. As I said in one of the posts, "follow the electrons". If you can find out where the current is going you it should lead to the bug and then to the fix.

What I mean by that is - the current might be going IN to VDD, but it may not be coming OUT of VSS. It may be coming out of a different GPIO pin that has been wrongly connected to ground or through some peripheral. Likewise it might be coming OUT of VDD but entering the chip via a different pin.

Tom

[phlp]

Thanks Tom. I've switch to the kinetis family but have similar problems. Please see my post here: Problem with Kinetis KL02.

Your comments will be appreciated!

Regards

Philip

[phlp]

OK, there may be another reason why the uControllers fail. The supply to the ADC unit (VDDA and VSSA) is not connected (left floating). Can it cause damage? The datasheet does say -0.1 < VDD – VDDA < 0.1.

Can anyone confirm this can permanently damage the controller?

Regards

Philip