MC9S12DG128

[LAR]

Hi,

I use to use the MC9S12DG128BCPV on a board that must operate at -32C, which it did, no problem. 

Now that the leaded BCPV is no longer available, I have switched to the Pb free CPVE version.  My first two boards now both fail at -32C and it appears that the micro is not running. 

I still have more tests to do to confirm this, but are there any known issues with the Pb free CPVE version at extreme cold temperatures?  It's operating spec is -40C.

Thanks for any help.

[LAR]

Is it possible that for this new revision (non B), that they have shrunk the die and that is why we are seeing problems at cold switch on?

[Alban]

Hello,

This is not very likely as even if die size has probably changed (different mask set), the test flow was adapted to fit the new device and controlled at tri-temp for qualification.

As your problem is permanent and on all parts, this should have been picked up at qualification (so would not have been able to be sold) and anyway at Test at the different stage in the production line.

(I'll watch where your SR# is going later today.)

Cheers,

Alban.

[LAR]

Two boards have now been fitted with 1.12 second reset devices in place of the 140ms device and both boards now seem to operate at -32C (still need to confirm 2nd after 13 hrs, but ok after 2 hrs @-32C).

Could it be then that new non B version doesn't accept the 16MHz clock at cold temperatures as well as the B version?  As the clock quality monitoring design changed in the non B?

As I have said before, the clock design has been perfectly fine on a few different boards for the last 3-4 years with the HC12 and the B version.

[Alban]

Hi LAR,

Unlike many competitors, FSL MCUs are characterized across Full Temperature range (except when specifically stated).

The long reset solving the trick could indicate that the Clock may be not ready at cold, therefore the MCU starting on a wrong clock or running away (I don't know your settings).

Instead of looking at ECLK (output of the MCU), it would be interesting to look at the oscillator clock and drive strenght.

- Have you calculated/measured the Negative Resistance / Safety Factor of your oscillator circuitry with the MCU in-situ ?

- When measuring on oscillators, you need to use a Low Capacitance oscilloscope probe. These are <1pF and are Expensive !

(FYI: Service Request was submitted as Quality default means it's not handled by Technical Support representative but by the Quality department for Quality problem investigation.)

Cheers,

Alban.

[LAR]

Thanks Alban,

I understand.  We do have the correct low cap probes and high performance scopes here, but it's very difficult measuring at -32C.  We have been monitoring the clock and as far as we can see, the clock does not degrade significantly in performance from 20C to -32C, but saying that it does appear to be a main oscillator clock problem.  It's strange though how all other boards design here, and there at least four different variants here that use the same clock design and micro, have all worked in the past with the B version with no problem.

If it isn't the clock, could it be a problem with the device starting up at cold and not recognising the reset line?

We have tried modifying the code to check the quality of the clock and switch to SCM.  Once in SCM we wrote to the COP (not $AA or $55), but this didn't work.

We also had the XFC pin floating (left over from HC12 design), but now we have it connected to VDDPLL.  Didn't make any difference to this problem though.

[Alban]

Hi LAR,

It could be, but only with your applications being involved...

The DG128 is used in Automotive applications and I can tell you that Automotive Manufacturers are quite harsh in their tests to ensure no module will easily fail.

What I commonly see is that usually (I don't say it's your case) applications are on the wrong border line of the specification and when the product is changed, it stops working...

The XFC pin is quite important. It gives the speed of the PLL and can potentially run it out of spec. But it's off for you...

Alban

[Alban]

Hello,

Every single device is being tested before leaving the factory.

That's why I'm wondering if you changed anything else in the production flow ?

- Comformance coating,

- humidity,

- oscillator components,

- PCB

- solder material,

- soldering temperature ...

Alban.

[LAR]

Hi,

Thanks for the reply.

Nothing has changed and we have been building these boards for the last two years.  We've fitted the new Pb free part to an old board and that is now the same.

The lowest temp that is powers up ok is -17C.  Below this temp, you have switch on, then off, then back on again for the micro to run.

Today, I will be monitoring clocks, etc and de-bugging the code.

Thanks.

[Alban]

Interesting info: switch off and on again...

It sounds like a vulgar IT Technical Support Helpline where you support them

I thought that Lead Free was requiring a different soldering temperature, because of the absence of lead.

Are my thoughts wrong ?

Have you tried parts from a different batch (code below MCU part number) ?

May be something is wrong with your batch, but I doubt it as the device is used quite widely and I have to say I would have heard from it...

So let's investigate the Application:

It seems the failure can easily be repeated, that is great.

When you lose the MCU, it would be interesting to follow the RESET, VDDs, and CLOCK lines.

May be when the board is getting cold, the power supply characteristics affect the MCU.

Do you have schematics (or part of it) you could disclose ?

Same for the PCB layout ?

So we can check the MCU environment.

If you've got any objection or other element, feel free to express !

Same for other Community Members, feel welcome to share your experience !!!

Cheers,

Alban,

[LAR]

Hi,

Pb free components are sodered at higher temperatures, due to the higher melting point of Pb free solder, but because we are military, we are still using lead solder on Pb free components.  We are having to use Pb free components in places, due to discontinued Pb components.

We are buying 40 parts from Farnell, which may be a different batch number???  There are also 200 off arriving on the 18/12/06 that we could try.  In the meantime, we are trying to understand why we are now seeing failures since we switched to the newer flash version.

We know it's not a board layout problem, because we have this micro on three different boards.  Two of the boards that have the new flash have the cold start problem. The other board still has the old flash, however, I am being told by the PCB manufacturer today that 18/126 have also failed during functional test at 20C.  They believe it is a flash problem and getting more old flash micro's to replace them.

We are currently monitoring the reset, supply and clocks and will let you know what we find.  I can tell you that the micro is run from a 5V supply and the clk is buffered by a gate to the EXTAL input that is powered from a 2.4V zener.  This is to meet to max XTAL input of 2.5V.  Never had a problem with this in the past with the old flash micro, but could it be a tolerance issue with the new micro's?

Thanks,

LAR.

[Alban]

Well LAR,

It is probably best you have this issue followed closely by Freescale.

Submitting a Service Request will allow your problem to be reviewed confidentially.

May be the problem is lying in the initial Flash programming. It seems strange that a power cycle would solve anything in this case though.

This is such a very high failure rate that something is definitely wrong somewhere !

Alban.

[rocco]

Hi, LAR and Alban:

---

Alban wrote:
. . . It seems strange that a power cycle would solve anything in this case though.

---

It is actually normal behavior in a low-temperature situation. With the first power-up the die is cold, but it doesn't take but a few seconds of self-heating for the die up to reach a working temperature. The second power cycle just gives it a fresh chance to start-up.

[bigmac]

Hello LAR,

Since you are using an external oscillator and buffer for the clock, I wonder if the problem could be in these components?  It might be that the newer MCU type is more critical for clock amplitude, and perhaps also risetime, than the older part.

If the oscillator is sluggish to start at very low temperatures, this may account for what you are observing.  This could be easily tested by delaying the release of MCU reset for an additional period - enough for the clock oscillator output to become stable, perhaps with a degree of self-heating of the oscillator also required.

Regards,

Mac

Message Edited by bigmac on 2006-12-1304:34 PM

[LAR]

Hi,

Thanks for all of the reply's.

We are investing the theory of the clock not being stable/correct amplitude at start-up for cold start-ups (thanks bigmac).  The existing clock circuit has worked fine for the last couple of years and on various different boards with the same design, but using the 'B' version only.  Maybe this new non-'B' version is more susceptable to a 'poorer' clock at cold temperature start-up's?

There appears to be a function to monitor the clock and switch to either the internal low frequency clock or do a reset.  We are looking at modifying the code to keep resseting until a stable clock is achieved (saves changing any hardrware). 

In the meantime, we are checking the operation of the clock circuit.  The clock is a 16MHz oscillator (XO91100UIT-16MHZ from Euro-quartz).  We buffer this using a single gate that is powered from a 2.4V zener diode to meet that max XTAL input of 2.5V.  Also checking zener voltage at extreme temperatures.

Still awaiting a response from Freescale tech support!

Message Edited by LAR on 2006-12-1301:05 PM

[Lundin]

To get a reset when the oscillator isn't working, simply disable the self-clock mode, bit SCME in register PLLCTL (it is enabled out of reset).

[LAR]

Hi,

Thanks for the info, but how can you clear that bit in the code if the oscillator is not running and thus presumably no instructions are being executed?

[Alban]

Hello LAR,

There is a stand alone clock inside the MCU.
It is called Self Clock Mode (SCM) and with the Clock Monitor (CM), you can get a Reset if the external oscillator is lost for a reason or another.
It is taking a reset vector called Clock Monitor Reset.

Alban,

[LAR]

Thanks Alban,

We have left the XFC pin floating in our design.  The device user guide recommends that this pin is connected to VDDPLL if the PLL is not used.  We do not use PLL.

I have connected XFC and VDDPLL together (pins are adjacent and I am now testing it at -32C to see if this cures the switch on fault, seeing as it is part of the clock circuit.

I'm still waiting for a response from Freescale, but in the meantime I fitted a longer reset device.  The old one was 140ms with a threshold of 3.08v.  This new one has a reset time of 1.12 sec and a threshold of 4.39v.  I fitted it to one board and left the board at -32C for 14 hours and it was ok.  So the longer reset may be the fix, but I am going to try two other boards first.

[LAR]

Thanks,

I submitted a service request earlier today, so I am awaiting a reply.

LAR.

[LAR]

Does anyone know why the 'B' was dropped from the MC9S12DG128B part number?