Coldfire MCF52254 having problems booting

[ARQuattr]

I have some custom boards using the MCF52254 which normally power up fine, but a recent batch is having a problem booting up frequently.  I see that when it is not running that the crystal is dead.  If I cycle the power quickly the crystal starts fine and the application boots normally.  If I let it stay off for too long (more than ~10s) the clock doesn't start and it doesn't boot.  The attached image shows the crystal circuit, which is based on the MCF52259 tower reference design.

I don't know of any changes between the last batch and this one, but they do apply a humiseal coating and I suspect it might be affecting the tuning.  I've tried to remove the coating and I don't think it had much effect, but I'm not sure I got enough off.

Any thoughts on what I could try?

Thanks

[TomE]

Have you read the Errata for that chip? SECF194 matches your problem, which is "OSC: Intermittent operation of crystal oscillator over full temperature range with greater than 25 MHz crystal.". It says to perform a "negative resistance test" (but assumes you know what that is and how to do it. So type "crystal negative resistance test" into Google and find lots of hits that you should read, but to understand your problem, read the "negative resistance" section of this one:

Fundamentals Of Crystal Oscillator Design | Analog content from Electronic Design

It has graphs showing that if your capacitors are too large you lose "negative resistance" and thus lose the gain margin.

> based on the MCF52259 tower reference design.

I'd check a few more reference designs. I've never seen one with a 10k pullup on XTAL before. That is connected to an output, so it isn't like it is pulling the input too much. Unless you can find a documented reason for this resistor I'd remove it. It may be there to support different oscillator configurations. Your different "switch on" times is obviously ramping the power rail up, and that ramp is going through that 10k resistor and changing the startup voltages on the crystal. It may be there to "kick" the crystal into starting, but if your power supply design is faster or slower than the one on the Tower it may not be working as expected or may be causing the problems.

In the Reference Manual for your chip there's "Figure 7-12. Crystal Oscillator Example". It doesn't show a pullup. It also shows 16pF caps on an 8MHz crystal. I'd expect the capacitors to get smaller as the frequency gets higher, and you're using a 48MHz crystal.

> humiseal coating

Which would be likely to increase the capacitance on the crystal.

Designing crystal oscillators properly is very difficult. Validating the design is also difficult. I've been through this and the CPU manufacturers' normal response is "ask your crystal maker" and the crystal makers say "not our problem, ask the CPU maker" so you have to work it all out for yourself.

I'd suggest you read through the tutorial from "John R. Vig" here:

IEEE UFFC | Frequency Control | Tutorials

Also read through this and follow some of the references:

Crystal oscillator - Wikipedia, the free encyclopedia

The crystal you're using has a "loading" specified by the manufacturer. You have to match this - I think that's what you've got wrong. The "loading" is the total external capacitance on the crystal, made up from the CPU capacitance, the load capacitors (16pF in your case), all the track capacitance and anything else - like your coating. The capacitors have to be selected so that the loading on the crystal is correct.

Then you should test for the "gain margin", which is probably low. So type "Crystal oscillator gain margin" into Google and start reading. That search found this, which

http://www.freescale.com/files/microcontrollers/doc/app_note/AN1783.pdf

That gives a very complicated way of checking the design. A simpler one to test for a margin of "3" (normal) or "5" (Automotive) is to get the crystal resistance from the data sheet, multiply that by 3 (or 5) and put a resistor of that value in series with the crystal. Then test it over a wide temperature range. It should work reliably over the entire range.

I'm a bit concerned about the default setting for the "LPEN" bit in that CPU. There doesn't seem to be a way to get it to start in "high power mode" or any description of what that is. Higher frequency crystals usually need higher driver power than slower ones.

The Reference Manual also documents the "OCLR[RANGE]" bit as "Support external crystal in the range of 1 MHz to 16 MHz.". 16MHz? You're running three times that! I'd say this may be an editing error in the manual, but this whole oscillator design and document looks very iffy to me. These sentences are cut/paste copies in the 52110, 52211, 52223 and 52259 manuals. Some of the chips are 25MHz (but may have been 16MHz originally) and the MCF52259 is the only one I can find rated at 48MHz. But the Reference Manuals haven't been updated, and may have other out-of-date problems.

Tom

[ARQuattr]

Thank you Tom for you quick and very thorough response.  I will review the linked information and other topics you suggested, but in the meantime regarding the 10k pull-up, I was a little confused by this at first also, but I believe it is related to the clock configuration settings for this chip.  7.6.4 of the 52259 reference manual shows that the XTAL pin needs to by high on reset for the device to enter on-chip oscillator mode.  The value is the same as what is used on the tower, as well as all the other values including the crystal itself.  (I have to also assume - and hope - that 16MHz crystal limit is a typo considering the tower uses 48MHz.)  But of course as you say other PCB design factors might cause differences, and certainly we are dealing with low capacitances that can easily be influenced by PCB design and coatings.

Thanks again, I will review the app notes and do some more testing.

[TomE]

Others have had problems with the crystals. 48MHz is rather high and unusual. Here's a thread where someone bought a 16MHz third-overtone crystal. The thread lists a part number for a crystal that should work, which lets me get the data sheet for that crystal and check the values

Re: Crystals 48MHz that works on MCF52259 ?

ABM7-48.000MHZ-D2Y-F-T

18pF load, 50 ohms ESR.

The CPU input pins are specified to be 7pF. The "load" of 18pF it the total capacitance across the crystal, so that's the two 18pF caps in series plus the 7pF pin loads in series plus the track-to-ground capacitance. Do you have an inner-layer ground plane under these traces? Some designers recommend a "hole" in the ground and power planes under these traces to reduce and control their capacitance. With double-sided boards or with a multi-layer with the inner layers empty it is easy to control the capacitance of tracks to a ground plane on the other side, but not so easy to control capacitance to inner-layer ground planes as the thickness of the inner insulating layers varies a lot more than the final board thickness between batches. Your PCB designer should be able to tel you the trace capacitance or you can calculate it here:

Missouri S&T Microstrip Impedance Calculator

To perform a "Negative resistance test" for a gain factor of 2 on a crystal with an ESR of 50, change that 10 ohm resistor to 100 ohms and test. For a factor of 3, use 150 ohms. If it doesn't work with that resistance, try reducing the capacitor value until it does (if it does).

> the XTAL pin needs to by high on reset

I missed that. I see that "M52259EVB_SCH.pdf" has a 10k pullup on Page 9, but "TWR-MCF5225X-SCH.pdf" doesn't. What Tower schematic do you have that shows a pullup resistor (and I wonder how the Tower board from the above schematic works at all)?

Tom

[ARQuattr]

Thanks again Tom,

     The crystal I chose is TXC 7M-48.000MAAJ-T which I believe is 48MHz fundamental, but I'm still concerned about the 16MHz max reference in the data sheet.  Perhaps Freescale can confirm whether that's a typo or not.

     The crystal has load capacitance of 18pF, but according to what you noted, the 18pF caps and 7pF pin impedance in series should give a load capacitance of ~4pF, correct?  I haven't seen many crystals with load capacitance that low, so I'm not sure what I'm missing here.

     I did the PCB design - it is 4-layer with a solid ground plane beneath the crystal traces.  I'll have to calculate the trace impedance.

     For the TWR-MCF52259, you should see J10 at D3 on the MCU page, which allows selection of the XTAL 10k pull-up.

     I still have to set up to do some of these tests, but I'm wondering if I should also try using a 16MHz crystal.

Thanks,

Angelo

[TomE]

> The crystal I chose is TXC 7M-48.000MAAJ-T which I believe is 48MHz fundamental,

http://www.txccorp.com/download/products/c/7M_c.pdf

Bingo!

The specified load capacitance for that crystal is 10pF. You're using a hardware design that is for an 18pF crystal. Who missed checking that?

> but I'm still concerned about the 16MHz max reference in the data sheet.

The reference isn't in the Data Sheet. There's one master copy of the "Clock Module" chapter which has been copied into all of the Reference Manuals for the chips using that module. It has missed out on getting updated match the chip. This happens a lot. The Data Sheet is OK, as it REALLY has to match exactly what the chip variant does. If the Reference Manual and Data Sheet contradict each other I think you can trust the Data Sheet more. Especially when it is so easy to reconstruct the "family tree" of the documentation, Just like matching animals with DNA, the documents seem to have standard "mutation rates".

> Perhaps Freescale can confirm whether that's a typo or not.

You should submit a report through the "proper channels". Go to Freescale's main site, click on "Support" and then "Technical Service Request". Submit a report and then tell us how if you get anywhere.

You'd be better off submitting the report through your Sales Rep. They have better communication back to Freescale than us mere mortals can get.

Tom

[ARQuattr]

> The specified load capacitance for that crystal is 10pF. You're using a hardware design that is for an 18pF crystal. Who missed checking that?

The 'J' version is supposed to be for 18pF based on http://www.txccrystal.com/images/pdf/number-crystal-basic.pdf

The datasheets are not very detailed, but the one I was using came from this DigiKey page 7M-48.000MAAJ-T TXC CORPORATION | 887-1140-1-ND | DigiKey which is http://www.txccrystal.com/images/pdf/7m.pdf  It's interesting that the datasheet doesn't even come from the same domain.  I hope I'm getting what I think I am.  But I'm still not sure I have selected appropriate caps based on what you wrote previously.

[TomE]

I should have looked for that second data sheet.

Some other factors.

Check (with a meter) that R1 in your circuit is actually 10 ohms. You might have a batch where (say) 100 ohm resistors were used by accident.

What is the effect of the 10 ohm resistor? At 48MHz the 18pF load has an impedance of 1/2Pi*f or -j184 ohms. It will also be phase-shifting by about 4 degrees, so it shouldn't be important:

http://www.dicks-website.eu/compleximp/enindex.htm

The capacitance of that resistor may be attenuating the output from the XTAL pin and reducing the loop gain and margin.

The ratio of the capacitance on the input and output of the crystal changes the characteristics. The two capacitors act as a voltage-divider. The higher the output capacitance, the smaller the signal from the crystal and the smaller the gain. In your case there should be more capacitance on the input due to R10 and its pads, but you might have high stray capacitance on the output due to track layout.

> If I cycle the power quickly the crystal starts fine

You may find if you monitor the power supplies and the crystal that during a fast power off there's enough voltage remaining on the power rails that the oscillator doesn't stop.

I'd like to run with OCLR[LPEN] set, but there's no option to force that condition from power up.

How have you got the CLKMOD pins strapped? "Table 7-1. Clocking Modes" shows that if XTAL is pulled high (as you have it) then the CPU runs from the relaxation oscillator unless CLKMOD[0] is high, in which case the pullup on XTAL is ignored.

So if CLKMOD[0] is high you don't need (and probably shouldn't have) that pullup on XTAL. Remove it.

If CLKMOD[0] is low then your CPU will be starting on the Relaxation Oscillator and somewhere in your startup code you're switching over to the Crystal. If you're doing that, then clear the LPEN bit to get the oscillator into "high power" mode and see if that fixes your problem.

I can't find any technical details on what LPEN actually does. This looks like a bad omission in the manuals and data sheets.

Tom

[ARQuattr]

Hi Tom, it's been some time but this issue still haunts us.  We have made a number of these boards and a significant portion of them exhibit this failure mode (on the first cold power-up the oscillator does not run, but if powering-up within several seconds since it was last powered, the oscillator starts running).

I went through your suggestions:

1. Regarding the crystal, I found some notes online that suggest for the 18pF load capacitance of the crystal I should be using something around 26-30pF caps.  I tried 27pF caps but that didn't help.  I also tried a different crystal with a 8pF load capacitance and various caps, and that still didn't help.  I also removed the 1MOhm resistor but that didn't change anything.

2. Regarding OCLR[LPEN], the bit is supposed to be 1 by default on reset, and the code (which is essentially the Freescale USB host bootloader project) sets it to 1 again before switching to the external oscillator.  I thought setting it to normal (not low-power) mode might help so I clear this bit, but it doesn't change the behavior.

3. The CLKMOD pins are both floating, but as I understand from table 2-1 there are internal pull-downs, so along with the external XTAL pull-up, this should put it in 'PLL disabled, use on-chip oscillator' mode.

Do you have any thoughts as to what would be preventing the crystal from oscillating?

Thanks,

Angelo

[TomE]

> Do you have any thoughts as to what would be preventing the crystal from oscillating?

Plenty. Let's go back to the beginning.

MARGIN TEST

I originally suggested that you MARGIN TEST the crystal. I don't think you've done that. Basically, if the margin is wrong then nothing you can do will be reliable if you don't fix this. I'd like to get my original suggestions out of the way before going on to anything else.

The test is very simple. The Data Sheet for the crystal says the ESR is "60 ohms max". To "margin test" with a margin of "3", replace R1 (the 10 ohm resistor) with 180 ohms. Will it work now? You may need to switch it on and off A LOT, but if it runs at all, it is OK. If it won't run, it has failed the "margin test". Keep reducing the resistor (150, 100, 80, 50 etc) to see what the margin is. If it fails at 180, change the capacitors. Try a SMALLER one on the input to the CPU (EXTAL) as that should increase the gain of the loop.

> but according to what you noted, the 18pF caps and 7pF pin impedance in series should give a load capacitance of ~4pF, correct?

No. Two 18pF in series gives 9pF. Two 7pF in series gives 3.5pF. Those two pairs in parallel give the sum, or 12.5pF. Then R1 and R2 and the pads and tracks on them add more capacitance, as do the crystal pads and all the tracks. You should measure the track capacitance on an unloaded board with a professional meter or bridge.

OSCILLATOR

Now try to find out what the oscillator is doing when it is working, when it isn't, and look for differences.

See if you can find a high VOLTAGE oscilloscope probe. One of the ones that goes to 1000V and is 100:1 ratio. The reason to do this is that the normal probes may have a 10MOhm input impedance, but they have pretty high capacitance that will affect the crystal more than you'd want. Otherwise, measure the crystal pins with a normal probe, but use a 1k resistor in series with the probe. You can work out from the frequency and the probe capacitance specs what it will do to the signal. Anyway, I'm more interested in the average voltage on the pins.

So when it is working properly, the average voltage on XTAL and EXTAL should be "in the middle somewhere". When it isn't working - well measure it, think about it and tell me. Either it is trying to oscillate and can't get going, or the oscillator is disabled because the CPU is in the wrong mode somehow.

When it isn't working, see if you can kick it into life by pulling EXTAL up and down a bit by shorting to VDD and VSS via some resistors. That should show if the oscillator is disabled. If that works, try reducing the 1M resistor. That is there to try and get the amplifier "DC Balanced". Theoretically, simple crystal oscillators can't start until there's some NOISE to amplify, that the crystal then filters to its operating frequency. Maybe your power supplies and startup and "too quiet" (very unlikely, this is only theory).

When it is locked up can you get it running by feeding an external oscillating signal into EXTAL?

RESET

Are you relying on the internal power-on-reset circuit or do you have an external one? Add an external one, or manually control RSTIN and see if that changes anything. See if a locked-up unit will start running if you cycle RSTIN. Do you have a debug connector on the unit? It should have RSTIN connected to it. Do you have an external pullup on RSTIN (as recommended)? Is RSTIN at a different voltage when it is locked up? What is RSTOUT doing when it is locked up?

What's the voltage on the TEST pin (working and non-working)? Do you have a pull-down on it? Add one. Ditto JTAG_EN and TRST (measure and pull).

POWER CONNECTIONS

Now if we've got the crystal and reset factors out of the way, time to check power. This chip only had one power supply (some of the other ones have lots more that need to be sequenced properly).

Do you have all the VSS and VDD pins connected? And VDDPLL and VSSPLL? And VDDA, VSSA, VRH, VRL?

How much bypass do you have on the boards? What's the difference in power supplies between your production testing, bench testing and as the customers use them?

POWER SEQUENCING

What supplies the 3.3V? Are there any OTHER supplies on the board, supplying 5V or 12V to anything? Measure their power-on sequences relative to each other. Which one comes up first? Is there any "leakage" between power domains - meaning do you have any 5V-driven signals connecting to any CPU pins where the 5V might come up and start driving a CPU pin before its 3.3V is up?

What is the difference in the sequencing between a "working power on", a "non working power on" and "the second one that works"? Add BIG capacitors to different supplies (to slow them down) and see if it gets better or worse.

Can any circuitry drive CPU I/O pins above 3.3V? This is called "Injection Current" and can cause lockups. Read the Data Sheet and search for "injection" to get the figures, but these only apply when the CPU is powered.

How FAST is the power supply? Is it a switcher or linear? Does it have "slow start". Is it Automotive (powered by a switch from a 12V car battery, so it comes up in microseconds), a bench supply that comes up fast or one that comes up slow? Is it a linear-transformer "Wall Wart" that turns on slowly sometimes and faster other times, depending on when in the mains cycle it was switched on?

Is it powered from USB?

Experiment with slow and fast power-on sequencing and ramping. Add series resistors and large electrolytics so the power comes up slowly and see if it makes any difference. Power it from a bench supply with a switch so it turns on fast.

You know a fast off/on has it work. Measure VDD with an oscilloscope and see how low it has to go to NOT recover.

Let me know the results of all of the above tests. With luck, you'll find the problem and fix it half way through the above list.

Tom

[ARQuattr]

Tom, I change R1 with 180 Ohm, and it behaves the same way.  I wasn't too clear though whether I should leave that part on for the subsequent tests.  I assume not, so I'm putting the 10 Ohm resistor back and continuing, but please let me know if I assumed wrong.

[TomE]

> Tom, I change R1 with 180 Ohm, and it behaves the same way.

Good. That shows that the loop gain of the system (Oscillator in the CPU, crystal and capacitors) has the recommended margin.

>  I wasn't too clear though whether I should leave that part on for the subsequent tests.  I assume not,

You are correct. This was a "margin test" at one of the limits. Other "margin tests" might be running at high and low temperature, high and low voltage. Once you've proved you're not unexpectedly close to one of those limits you can continue with other tests under normal conditions.

Another thing you should do as well. You have some boards that work OK (starting up every time) and some that don't. You should conduct comparative measures of all signals you can get to between those two boards, looking for differences. If all the "good" ones average (as an example) 1V AC on one pin of the crystal and all the "bad" ones average 0.7V then you would have a difference to focus on. If the Reset or Test pins are at different voltages, or supply different currents when shorted to ground through a milliamp-meter, then that would be a difference to investigate.

The Humiseal coating might have trapped moisture or contaminants which may be providing leakage between pins that have weak pullups or pulldowns. I would suggest taking a "bad" board, stripping off the Humiseal, giving it a thorough clean and see if that fixes it. If it does you can start cleaning off another board in small patches.

Tom

[ARQuattr]

Tom, I did some more testing today and I seem to have a fix.

Margin test: I replaced R1 with 180 Ohm, and the oscillator started up the same was as before (not when cold, but after a short power cycle).  It did this reliably as though there was no effect from the resistor change.  I put back the original 10 ohm resistor.  I measured an unpopulated board and the capacitance from either crystal pin to ground was 3-8pF, but between EXTAL and XTAL I measured 0pF.  I don't have the greatest meter though.

Scope: I probed EXTAL and XTAL.  At first I tried with a 1k resistor in series with the probe but the signal was heavily attenuated, so I just used the (10:1) probe directly.  When working normally, EXTAL read 2Vp-p, 1.3V mean.  XTAL was 2.4Vp-p, 1.5V mean.  The frequency was 48.0007MHz.  When powered up cold and the oscillator doesn't run, the EXTAL pin is at a steady 2.75V an XTAL was at 3.0V.  If I ground either XTAL or EXTAL through 1k, the clock starts running immediately.  I reduced the R8 value to 100k then 10k and even 1k, and it didn't change the behavior.  But if I short R8 briefly, the clock starts running.  If I tried to inject any clock signal the clock started running immediately.  I didn't try removing the crystal and just driving it with an external clock. I assume that would have worked fine.

Reset:  While the device is 'locked' on a cold power-up, asserting the reset pin does nothing.  The RSTOUT voltage when running is 3V and when locked, the pin is at 0V.  The RSTIN pin is normal 3.3V in both cases.  I assume RSTOUT is low when not running because the PLL is not locked.

JTAG pins:  TEST and JTAG_EN are both strapped to GND, but I checked the voltages to be sure and they are 0V.  TRST is pulled high on the board, but I also tried grounding that and it didn't change anything.

Power:  All the VSS and VDD pins are connected, as well as VDDPLL, VSSPLL, VDDA, VSSA, VRH, and VRL.  There is a total of about 3uF of 0.1uF decoupling caps on the board about 10 of them surrounding the MCU.  The power is supplied by an LDO with 20uF on the output (10uF + ferrite + 10uF).  There is a 5V charge pump for the USB, but it is not activated on power up - it is enabled by the firmware later.  When I measure the power up of the 3.3V rail, I see the voltage rise from 0 to 3.3V in about 200us.  Cycling the power and watching the voltage decay on the scope, I could determine that if I power up with the 3.3V rail above 100mV it would start oscillating.  If it was below that, it would not.

The device is normally powered by 3xAA batteries, and there is a switch on the device.  I connected the board to a power supply set for 4.5V instead of the batteries and powering on using the switch on the device like normal, gives the same result.  Leaving the device switch in the on position and powering on at the power supply causes it to work even on 'cold' starts.  So I tried turning up the voltage knob manually and even as fast as I could (maybe 100ms) it continued working.

So I tried adding large caps to the 3.3V rail, starting with 1mF.  This produced a ~6ms period from 0V to settled at 3.3V.  The device continued powering up reliably.  I reduced the capacitance to 100uF, then 47uF, and it continued working fine.  The ramp up period was about 500us with 47uF.  I also tried with just a series 1 Ohm resistor from the battery (with no extra caps), and this also had the same effect of slowing the voltage ramp-up and the cold starts worked, but of course with the voltage drop.

So at this point the device appears to be working fine with only the additional 47uF cap on the LDO output.  I don't know if the rate of voltage rise is the root cause, or if there is still some oscillator issue and this is just a workaround.

Regarding your questions about coating from your last post, a while ago I did indeed find that removing the MCU, cleaning the coating, and replacing the original (or a new) MCU made the problem go away on most units.  So we did this to a number of units, but the subsequent production run had no coating and the problem persisted.  This is why I'm back here now, because it became apparent that the coating was a bit of a red herring, or at least not the root cause.

I feel better that I seem to have a fix (and we will test this on more units to confirm), but I'm not very satisfied that I found the root cause.  I haven't seen limitations on voltage rise time for any MCUs, and I've had a lot of similar power supplies operate other MCUs with no issue.

Any thoughts?  Also, thanks again for your awesome support.

Angelo

[TomE]

> When I measure the power up of the 3.3V rail, I see the voltage rise from 0 to 3.3V in about 200us.

That's pretty quick. Freescale don't have a specification on the power up ramp time for this chip in the Data Sheet. They DO specify it for some of them. As detailed here, the ramp time for one of the more complex chips (with multiple power supplies that need to have specific relationships when powering on and off) is 50ms:

https://community.freescale.com/message/456494#456494

That refers to the MCF5475 Data Sheet as a good example of documentation, which says the minimum ramp time for that chip should be ONE MICROSECOND.

I suspect that could be an 8-year-old typo as the almost identical section in the MCF5235 manual says the minimum ramp time for that chip should be 1 millisecond.

The other part I'm familiar with the the MCF5329. It doesn't have a written power ramp spec. We had to add "very slow start" to the power supplies so that the oscillator would be running before the SDRAM controller pins are enabled or the whole thing wedged. The Oscillator is only guaranteed to run from 3.0V, but the pins are enabled at 2.6V. It takes a very slow ramp to get to 3.0V before it gets to 2.6V! In spite of that, the oscillator seemed to start at about 1.6V, so as long as the ramp is long enough so the oscillator is fully running before 2.6V the chip would wake up OK. In our case that mean a ramp time of 40ms. Details here:

https://community.freescale.com/message/69745#69745

If you search for "ramp power" in this forum you'll get plenty of hits. If you search for the strange word "undeterministic" you'll get some hits too.

I suspect you could have a problem relating to getting the oscillator running (and providing clocks to sensitive internal bits of the chip) prior to some voltage-level sensitive circuitry detecting and generating internal reset signals, or enabling some pin drivers somewhere.

R8 may be partly to blame, but you tried other values and nothing fixed it.

> the EXTAL pin is at a steady 2.75V an XTAL was at 3.0V.

If it was a simple amplifier/inverter, then 2/75V on EXTAL should force XTAL low, and then it should start oscillating. I don't know what sort of internal circuitry could lock up with the input and output both high. It looks like the "slow power ramp" runs the circuit through a state where it can start better.

> So at this point the device appears to be working fine with only the additional 47uF cap on the LDO output.

> ramp up period was about 500us with 47uF.

3.3V in 500us or 6600 Volts/Sec. That's 6600A/F or 6.6mA/uF or 310mA to charge up the 47uF capacitor. So what is providing that current limit?

It could be the LDO current limiting. You have to be able to prove that from the specification of the LDO in order to sign off on a reliable fix.

It might be the series resistance of the batteries that is limiting the ramp time. Better batteries might defeat the "fix".

What about temperature extremes? Will the "resistance" or capacitance change at the temperature limits?

Better not use an Electrolytic, as those things dry out after a few years, and the fault will return. You might have to specify a Tantalum or Ceramic to guarantee the ramp will stay "slow".

It was failing at 200us and working at 500us. Where's the actual failure point" It may be at 220us or it may be at 490us, and without measuring (and testing 10 or more units) you won't know how close to the failure your production run will be. I'd have a design point at least 3 or 5 times higher than the the average to guarantee being above three-sigma. The best option would be to use an LDO that have pins that allow for a programmable ramp time.

Tom

[ARQuattr]

> 3.3V in 500us or 6600 Volts/Sec. That's 6600A/F or 6.6mA/uF or 310mA to charge up the 47uF capacitor. So what is providing that current limit?

Good question.  Note that I wasn't giving rise time figures, but the time to settle after a slight overshoot (~3.5V peak) following the ramp-up.  The initial 0-3.3V rise was more like 100us in the original design and ~200us with the added cap.  But still it's a good question about the limiting factor.  The LDO is 1A rated and has a 2.2A current limit.  I'm sure there is some trace resistance, but probably not too significant.  The battery ESR seems the most likely reason, which I agree makes it more subject to non-design conditions (battery type, state of charge, etc.)

I tried to go to 47uF because the caps on the board are currently 0805 size and the highest value I can practically get in that size is 0805.  (I'm trying to avoid a PCB revision.)  But there are three of these in the regulator circuit, on on the input, one directly on the output, and another after a ferrite.  So my intention is to replace all three, which would give an increase of (-10+47)*3 = 111uF (+/- tolerance).  I felt if it worked with 47uF added, ~110 should be good.  But you make a valid point also that I should really be characterizing, i.e. finding the failure point with several units, and account for temperature and other factors, etc. to be sure I'm picking safe values.  We will be doing some more testing before making a final call on cap and/or PCB changes.

By the way, these are all ceramic caps (as I'm sure you gathered when I mentioned the package size).  I generally use ceramic over electrolytics unless rather high capacitance is needed, and definitely stay away from tantalums whenever possible.  In hindsight, a couple small electrolytics would have probably been prudent on this regulator, but again, I hadn't seen a case where a too-fast voltage ramp up caused issues.  The capacitance chosen provided a very stable voltage considering the current draw (average ~200mA), so it didn't seem going higher was necessary.  Next time I'll be sure to watch for this.

Thanks

[ARQuattr]

You're right Tom, sorry, I didn't read through all the posts again carefully and was focusing mainly on the last posts.  Thanks again for a thorough response.  I will go through all your suggested tests and report back.