36MHz oscillator start up failure

[gj2]

Posted on May 27, 2005 at 11:27

36MHz oscillator start up failure

[gj2]

Posted on May 17, 2011 at 12:07

Hi,

Does anyone have experience of using a 36MHz crystal oscillator with the uPSD? I have read three other posts on this subject, but they were concerned with type of crystal and circuit selection. We have used the standard circuit from AN1843 (attached, as it appears not be available anymore) - with an LC filter to operate a 36MHz 3rd overtone crystal. The circuit works fine on our prototype boards, and on most of the production boards. Crystal is from NDK, and circuit values are unaltered from the app note. Layout is close to the device, with a local ground plane and all other tracks routed away from the crystal. Boards are manufactured on a high volume, automated SMD line. We have a high failure rate of production boards not being programmed. They pass visual inspection but fail to flashlink. The common fault so far has been traced to the oscillator not starting up. We have tried changing crystals and this sometimes leads to success. Changing surrounding parts, including a series drive level resistor and parallel feedback resistor all seem to have little or no effect. When the oscillator is running it seems pretty stable, and the use of a 'scope probe or casual finger will not affect it. I would greatly appreciate hearing from anyone else who has had similar problems. Many thanks.

[jdaniel]

Posted on May 17, 2011 at 12:07

glec,

I think you have traced your problem to an incorrect and coincidental source. The oscillator is not involved in the FlashLink operation, since the JTAG programmer provides its own clock. The crystals failing to start up properly is most likely indicative of some other problem. I'm led to believe that the devices should program just fine even if there were no crystal on the board.

[gj2]

Posted on May 17, 2011 at 12:07

phaze426,

OK, thanks for yout help. Indeed the devices are JTAG programmable without a working oscillator. I got your message and went to check it out. I tried a board that I had previously tested and programmed. I shorted C2 to stop the clock, and then tried the JTAG chain again. It still worked. Great. However, there is something really strange with the JTAG programming and the clock.... Oddly enough - perhaps ironic - starting with a working unit, when I removed C2 (instead of shorting it) the clock still ran!? When I had erased the uPSD it stopped!So I reprogrammed it. Checked again - it was running! Here's the strange bit - I borrowed a colleague and he checked the clock whilst I programmed it and erased it. During all operations it showed a healthy 36MHz clock on the crystal, despite the removal of C2. And after an erase or programming just flash, the clock disappeared again. But after programming the CPLD - the clock persisted. Even persisted after power cycling the board. Upon further investigation it seems that the removal of C2 has little to do with this, as it shows the same behaviour when is C2 replaced. So I have identified one optional capacitor in the BOM, realised that PSDsoft Express must be controlling the oscillator in some undocumented way, and got no nearer the reason for our production failure. But I have had an interesting afternoon finding out 🙂 Cheers for your input - can anyone explain what PSDsoft Express is doing?

[jdaniel]

Posted on May 17, 2011 at 12:07

glec,

When you mention C2, I assume you're talking about one of the caps to ground as per the app note? If so, here are some comments: - Removing this cap and having the clock still run surprises me not at all. Caps are typically spec'd at around 18pF for the capacitors and you can EASILY get enough stray capacitance to common get them to settle into an oscillation without any external capacitance whatsoever. - The clock stopping on a blank device doesn't surprise me either. Remember, this isn't JUST a microcontroller, but a whole system built into there. Nothing says that if it knows it has a completely blank chip, it has to fire up the 8032 core. - C2 is not ''optional'' just because your board happened to work when you removed or shorted it. - I think you learned alot this afternoon. Think about it. You were originally saying that the common link as to WHY the devices wouldn't program was that they all had oscillators that wouldn't start. Now you know that it's most likely the exact OPPOSITE that's happening. The oscillators don't start BECAUSE the devices don't program. Try looking into your JTAG circuit. Check the component values you're using against those used on the DK3200 development system from ST. Also, try another JTAG programmer. Finally, are you using PSDSoft express to do the programming or FLink.exe? Are you assuming any particular timeout values within the programming. Take a look at the uPSD datasheets with regard to flash timing and you'll see it can take a LONG time for the flash to erase, etc. In my experience, this is usually worse the first time they are programmed. Hope some of that helps a bit.

[gj2]

Posted on May 17, 2011 at 12:07

phaze426,

Thanks for your reply. Yes C2 is the reference given in the app note that I had attached. I was being a little facetious about the optional component - it was a Saturday and I was in the office!! I stand by my surprise of the stopped clock. These devices are two slabs of silicon; a processor and some memory/CPLD functions. A standard micro system - so we are told - and I don't expect microprcessor clocks to stop when the memory is erased. As far as I know the clock oscillator is part of the processor silicon, and the only way to stop the clock is with power down mode. This is not the reset state of the PCON register. Anyway, I have tested more devices that have failed in production using my PSDsoft Express (v8.40). We have seen the same behaviour with nearly all of them - when first programmed/verifyied (by me) they request confirmation that the device should be erased, then proceed through erase, program and verify. All saying OK. But the devices do nothing. So I re-program them. Thie time the blank test passes and the programming continues without a request to erase them. Again, all verification passes and indeed further manual verification passes. When a manual erase is tried, it says the device is already blank!! In each case the security bit is unused and the report says that the device is not secured. I will try more failed devices - this time only operating on parts of the system (flash, boot flash, CPLD) at a time. Thanks for your comments about the erase times etc, which I take on baord, but really the verification should fail if the device has not been programmed properly - and I would expect to be able to erase it again anyway. Any ideas anyone????

[jdaniel]

Posted on May 17, 2011 at 12:07

glec,

I don't want to seem pedantic here, but this chip is certainly NOT comprised of two slabs of silicon. What they've done is purchase a processor core mask and masked it in with their own memory and other functionality. You should notice also that there are some functions that are part of the processor core and weren't there in the 8032, so that should give you some idea about how the system is comprised. (For instance, they have purchase a piece of watchdog timer IP from someone and masked that in as well). I'm not saying that they're definitely holding off the clock when the device is unprogrammed, but you certainly can't rule it out by saying that they've just attached some wires to a bond-out 8032 internally, because that's not nearly the case. While I can't say much more about your still-mysterious stopped clock, I can say that I've seen the failure mode where you're unable to erase and program them. In all instances in which this happened to me, I had a software bug that put the processor into a tight loop and DESPITE what ST says, this CAN screw up their JTAG interface. What I typically do when I run into this problem is first try holding the board in reset while I program it (this works the majority of the time). If that fails, I try the whole ''taking it out of reset and immediately hitting the program button'' tactic. I know that ST has had some issues like this because there's a note in the release details for PSDSoft Express 8.40 where they indicate that they now add a flag to the CPLD programming that, by default, leaves the JTAG interface active during reset. There's also another interesting note in your post. You say that the first time you program the devices it prompts you for an erase. That, in and of itself, is not right. The devices come from the factory completely blank and should program without any prompt for the first time. Are these surplus chips or something?