QD4 internal clock/FLL unstable? Large production facility issue, LED light flickering ...

[fat_wombat]

Hello,

we are using a small QD4 to control a LED daytime running light appication, which is in pre-production status. Suddenly, customer complains about visible LED light flickering.

The LEDs are dimmed by 200Hz PWM signal. Once on every 100 pieces, right after the first flash , one QD4 does exhibit very unstable dimming PWM, both frequency and duty are jittering by some 20%, which - unfortunately - results in visible and unacceptable LED flicker...

Moreover, the jitter is temperature dependent, almost disappearing when the uC is getting warmer, but returning back when uC is getting colder again.

This is a hardware PWM with a dedicated timer, driven by the internal clock.

I am suspecting the FLL loop in not being able to lock in, but why, on earth, would this happen only once at 100 and not with every single piece...?

How can I tell with the QD4 if the FLL has really engaged and locked in? I can't find any hint in the datasheet, I don't see any flag, signalling a proper FLL operation.

Any help or hints would be highly appreciated!

Here is the ICS initialization routine, straight out of the CodeWarrior InitializationExpert, we did't change anything there, in fact, those are simply the default register settings after POR:

  //SYSTEM CLOCK init
 
  //Initialize ICSTRM register from a non volatile memory
  ICSTRM = *(unsigned char*far)0xFFAFu;
  //Initialize ICSSC register from a non volatile memory
  ICSSC = *(unsigned char*far)0xFFAEu;  
  //internal clock selected
  // ICSC1: CLKS=0,IREFSTEN=0
  ICSC1 = 0x06u;                        
  //ICSOUT is TWICE the bus frequency!!!
  //the bus frequency is 4000000Hz (8Mhz divided by 2, BDIV = 01, default after reset!)
  //ICSC2: BDIV=1,LP=0
  //BDV = 1 defines the ICSOUT frequency as clock freq (16Mhz) divided by 2!
  //since ICSOUT is twice the bus frequency, the BUS frequency is 4 MHz !!!
  ICSC2 = 0b01000000u;  

[donw]

My first quess, since it only happens to some devices, is that you have a hardware problem which is upseting the uP.

I pressume you have quite high currents flowing inthe LED circuitry?

Maybe these are causing a spike into the uP (via power or ground lines), causing a reset or erratic operation.

What bypass caps do you have on the power supply, at the regulator and at the uP?

Bypass capacitor values vary with temperature (mono caps & tants).

To provoke the issue, increase the switching currents as much as possible, increase the pulsing rate,

and start removing all bypass caps. maybe to will be able to make it fail consistantly.

Check especially ground tracks from the uP to power source. They should not carry high switching currents.

[fat_wombat]

Hi donw,

of course we did check the uC supply - it is clean and solid. We have quite an experience with uCs in automotive apps (but not small FSLs up to now) and the power supply has been taken care of.

I am quite certain that this must be a FLL issue. At the same time, I am not qiute certain of what exactly our production programmer is doing.

Would it be a problem for the FLL ot lock, if our production programmer erases the value, stored at the FSL fab in the oscillator trim cell FFAEhex before (or during) flash programming?

I mean, the default value after reset for the calibration would be 128dec, if the uC program then tries to fetch the factory-preset calibration byte, but the prod. programmer has already deleted it ( set it to 0), then the FLL will try to lock to  - I think - the highest frequency possible.

Would this be a problem for the FLL? I thought, it must be guaranteed for the FLL to lock in within the whole 0 ... 255dec calibration byte, otherwise it does not make sense to me and FSL must have done something wrong with this small uC, since it can lose its reliable clock in such a situation, but it never knows that it is losing its clock ....

[Lundin]

In addition to what has already been said, how much current are you driving through the MCU pins? Do you feed the LEDs directly from the MCU or is there a buffer in between? Typically LEDs will be spec:ed to 20mA, which is about exactly as much current as the pins can handle. If your series resistor to the diode varies with temperature, you may be stressing the MCU pin outside of specs.

[fat_wombat]

Hi,

Well, it seems that we've found the root of the problem: the manufacturing facility was performing mass erase of the flash without saving the factory trim values @FFAF and FFAE first :smileysad:

After flash erase, the FLL is trying to lock in to 0xFF (lowest frequ possible, approx. -20% apart from the nominal frequ); the real mean trim value would be around 0xA5, thus far away from the 0xFF ....

Nevertheless, I am a little bit angry at Freescale -

1) the trim value should have been protected somehow in the flash, it is just too easy to erase it! :smileysad:

If you lose it, you actually can throw the µC away.

2) why can't the FLL lock in with 0xFF or 0x00 instead of some value in the middle? Something is wrong with this oscillator, how can I be sure that it is stable with a trim value somewhere in the middle of the trim range, if it is obviously not stable with a lowest r the highest trim value?

Having said that, I do like everything else about the QD4; it is a fair deal for the money...

[bigmac]

Hello,

If you are using CW or P&E programming tools, loss of the factory programmed trim value should be of no consequence, as both tools have the ability to set a recalibrated trim value into flash memory.  Doing a recalibration will likely provide more accurate bus frequency setting because it is done in situ within the actual end product.

During POR, the ICS trim register will be set to 0x80, the exact midpoint value.  With this trim setting, the FLL will always lock, but the refference frequency will be somewhere within the production tolerance of 25 to 41.7kHz.  The DCO frequency will then be within the range 12.8 to 21.3 MHz, and the bus frequency 3.2 to 5.3 MHz.  After applying the correct trim setting, the reference frequency will be nominally 31.25 kHz, giving a DCO frequency of 16 MHz, and a bus frequency of 4 MHz.  It is now possible to alter the BDIV setting to increase the nominal bus frequency to 8 MHz maximum allowable value.

If the non-volatile trim setting is in an unprogrammed state, there is no point in transferring this to the trim register - the code should then flag the unprogrammed state as an error condition.  During this condition, the BDIV setting must not be altered, otherwise the maximum bus frequency may be exceeded.

Note that the reference period will be proportional to the trim value, so the reference frequency will actually follow a hyperbolic function, i.e. a reference period range of 24-40 us, with a central value of 32 us (31.25 kHz).

Regards,

Mac

[fat_wombat]

Hello BigMac,

can you please be more specific about the way the P&E programmers can re-calibrate the µC?

Do they need an external reference frequency connected to a compare/capture input of the µC and and a special application, flashed in the µC for this purpose or can they do this on-the-fly with an empty microcontroller?

I've tried to get the idea looking at the P&E docs online, but unfortunatelly I can't so far.

[peg]

Hello,

A P&E Multilink or a Cyclone will calibrate the internal clocks of all freescale devices if asked.

This is done without any additional hardware or reference or pre-loaded code in the uC

Exactly how it is done is a trade secret of P&E.

It generally works quite well.

The idea is to download your code then calibrate and it will burn the trim values into the suggested NV locations.

It is up to the code you supply to copy these across to the volatile working registers at power up.

[bigmac · Accepted solution]

Hello,

I presume that you would have already compared a faulty unit with a good unit, on a pin-by-pin basis, using an oscilloscope.  Are you actually able to debug the faulty units using BDM interface?  This may provide more insight about the problem.  I also presume that reprogramming a faulty unit does not affect the problem.

I would want to rule out that you are not getting a periodic reset condition, maybe due to LVD or COP timeout.  If you are using the default 32kHz clock source for the COP, rather than the bus clock, the COP timeout period could be subject to unit-to-unit variation of +/-30 percent from nominal value.  If you place a break point within your initialization code, this should reveal whether a reset is occurring.  The SRS register contents would then reveal the source of the reset, if one should occur.

If the programmer does a mass erase prior to programming the code, the factory calibration for the internal reference will also be erased, and should be recalibrated during the programming process.  For those cases where oscillator calibration is critical to the operation of the project, I would normally test the flash stored calibration value within the initialization code.  If a value of 0xFF for an unprogrammed state, I would provide a visual indication that can be observed during the final test of the product, to indicate that the programming was incomplete.

If a value of 0xFF is loaded to the trim register, this would give a low bus frequency, maybe exacerbating a potential COP timeout issue.  Under these conditions, the bus frequency could also be subject to +/-30 percent unit-to-unit tolerance.  You should be able to verify the actual trim setting during the debug process.

The datasheet is not clear whether the untrimmed internal reference frequency range (25-41.7kHz) applies over the full trim range, or is the possible variation at a mid-point trim setting.  If applicable to mid-point trim, it would appear possible that the DCO output frequency could reach an extremity of its frequency range before lock occurred.  However, I would not have expected rapid swings of DCO output frequency under this condition.  On this basis, rapid changes of PWM duty cycle would not be anticipated, just a PWM frequency error.  For FLL operation, there is actually a small amount of jitter normally present after lock has occurred.

Another approach to identify whether clock frequency swings are causing the problem might be to load some special test code into a faulty unit.  The test code might setup a 50 percent PWM signal at a somewhat higher frequency, maybe 10-20 kilohertz.  Any output jitter might then be more easily identifiable with an oscilloscope.

Regards,

Mac

[donw]

my experience with the S09 family is with the JM60 only, which has been very rock solid

(compared to older uP families), so can't help you with the PLL of Qd4