Show your layout. And what specific crystal you are using?
I'm using an unknown 12 MHz crystal that I found in my components bin.That is your problem most likely. Try a crystal that you actually have a datasheet for.
Check the crystal's series resistance and load capacitance values are reasonable. Datasheet Table 26 offers specs of 18 or 39pF for the two caps.I suppose I can desolder the crystal and check capacitance and ESR with an LCR meter. I have the Keysight U1733C meter which ranges from 100Hz to 100kHz for testing capacitance - should I be using the low or the high end of the measurement?
LPC81x errata (https://www.nxp.com/docs/en/errata/ES_LPC81XM.pdf) it seems to be finicky about VDD ramp up time sect.3.7 and osc issues below 1.9/2.3V (not relevant at 3.3V).I did see the errata previously and noted both of those points. My supply voltage is good and I'm able to break into the firmware with my debugger and observe the loop waiting for PLL lock, so that tells me that the MCU is indeed starting up and executing code correctly.
I use the finger test to check if an oscillator is weak, touch OSC IN and it should keep running. Or observe the start-up time with a scope with various loading caps.My problem is it's almost never running and it's seemingly random as to when it does run.
Shoot – I have several hundred crystals and none of them have datasheets. Am I totally out of luck and need to order & wait for a new crystal?I'm using an unknown 12 MHz crystal that I found in my components bin.That is your problem most likely. Try a crystal that you actually have a datasheet for.
Would you be willing to offer specific suggestions for improving my layout? I am quite new to PCB design and it would be very helpful to get some expert input. I will also probably spin a new version of the board so I would definitely take your feedback into my next design.Also, I don't get this layout. Where is the crystal and capacitors and traced to the MCU?
Ok, I think I found those. The layout is not ideal, but it would probably not be the source of the crystal not starting entirely.
Shoot – I have several hundred crystals and none of them have datasheets. Am I totally out of luck and need to order & wait for a new crystal?What is the source of those crystals?
Would you be willing to offer specific suggestions for improving my layout?Try to place the crystal as close to the MCU as possible (shortest traces). Avoid VIAs if possible. Do not have that spaghetti of traces and broken ground planes cross the crystal traces.
They're all surplus parts that I've acquired from many years of collecting components – no idea about their individual origins.Shoot – I have several hundred crystals and none of them have datasheets. Am I totally out of luck and need to order & wait for a new crystal?What is the source of those crystals?
The issue with random crystals is that not all of them are the same. It may be some strange 3rd harmonic crystal, which will not work in an oscillator designed for the fundamental crystal. Chances are low, but a random bin of parts may contain anything.Yeah, fair point. I really prefer to use existing components rather than buying new ones when possible, though. Do you think building a simple Colpitts circuit or something like it for testing crystals is a good idea? Or is it really more trouble than it's worth? I would understand for high frequencies (hundreds of MHz+) that I'd need tight tolerances, but 12 MHz seems quite low doesn't it?
You don't necessarily need to order new crystals, but if I were you, I would be changing the crystal, not the capacitors. You don't even need to solder the new crystal in, just hold the pins in the holes and see if it starts.Are you saying that I can keep the old crystal soldered into place but just touch a new crystal to the old leads? Doesn't the parallel capacitance affect it?
Got it. Wonderful suggestions all. Thank you! I will be revising my layout to take all of these points into account.Would you be willing to offer specific suggestions for improving my layout?Try to place the crystal as close to the MCU as possible (shortest traces). Avoid VIAs if possible. Do not have that spaghetti of traces and broken ground planes cross the crystal traces.
You don't show the mechanical dimensions of your crystal, so it is hard to judge, but in this case it looks like a better placement for it would be where you have the capacitors now - close to the IC. And capacitors could go on the other side using holes from the crystal as vias.
Are you saying that I can keep the old crystal soldered into place but just touch a new crystal to the old leads? Doesn't the parallel capacitance affect it?
Could also be that the crystal is damaged? If it was dropped at some point, the crystal could have chipped or cracked, and who knows how it might behave then.
Are you saying that I can keep the old crystal soldered into place but just touch a new crystal to the old leads? Doesn't the parallel capacitance affect it?No, remove the old one, I suspect is is bad anyway. Just try a few new ones without soldering.
Capture with the scope the very beginning of the oscillator enable process. It is typically pretty easy to do since XOUT line goes high when oscillator is enabled. See if oscillations start and then die down, or don't start at all.
Also what code do you use? I'm not familiar with NXP part, but some parts have automatic gain control, but it needs to be turned on only after oscillator is stable. Some parts just have settable gain, and you need to set it to the correct value.
Ok, it looks like oscillator here is pretty primitive with no configuration options. You still need to follow things described in the Section 4.3.3 of the User Manual. Pay attention to disabling of the pull-up/pull-down resistors.
The classic (modern) oscillator is a CMOS inverter connected to the two crystal pins. Then, you put a reisistor of some value across the crystal to put the inverter into the middle of its input range. The selection of the resistor value needs to be adjusted to get the best startup. There will also be resonating capacitors, typically from each crystal pin to ground. The series combination of these two capacitors should be equal to the manufacturer-specified resonating value, minus the stray capacitance of the board and IC.
I made boards with the Xilinx XC9500 (5 V) CPLD family for years. Then, I was forced to move to the 9500XL family (3.3 V) and they added a "weak keeper". This is a non-inverting gate that feeds the pin back to itself with an ~ 20 K resistor, to prevent input pins from floating. This fouled up my crystal oscillator circuits. I had to go down to a 10 K resistor across the inverter to get it to start reliably.
That LPC chip already has that resistor, it should not need anything other than the crystal and load capacitors,
Also, OP, can you show us your soldering? You don't have a mess of flux all over the place by chance? Some fluxes are conductive.[attach=4][attach=5][attach=6]
CMOS gate oscillators can be picky about crystal losses because of low gain which makes discrete transistor oscillators more reliable. Check page 5 of TI's application note available here:
https://www.ti.com/lit/an/snla290/snla290.pdf?ts=1598754949238 (https://www.ti.com/lit/an/snla290/snla290.pdf?ts=1598754949238)
Good article on how to measure Xtal characteristics (URL)
I don't know about the LPC family specifically, but ST has excellent info in their appnotes:
https://www.st.com/resource/en/application_note/cd00221665-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf (https://www.st.com/resource/en/application_note/cd00221665-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf)
I think in part because ST seems to prefer a weaker oscillator, thus requiring a higher ESR crystal, which has smaller loading capacitors.
The oscillator is an analog circuit, of course; the traditional inverter circuit simply has a maximal amount of transconductance (peaking around its transition level, and it stays biased there thanks to the feedback resistor). The crystal is a three-terminal network, which has to have a ground connection in order to have phase shift (which, using a 2-terminal crystal, implies the loading capacitance needs to be greater than zero). As a network, it has impedance and gain parameters. Impedance times transconductance times network gain is loop gain, and it must be greater than 1 to sustain oscillation. For equal loading capacitors, we can assert the crystal network's gain is about 1, so we're mostly concerned with impedance and transconductance.
Nearly consequential to this, is the loading capacitance itself. This will have reactance comparable to the impedance of the network at resonance. And typically, crystal ESR is a modest fraction of this.
Crystal resonant frequency also depends on capacitance; you can pull the resonant frequency (over a narrow range) by changing the loading capacitance, of course only if you don't mind that you're changing impedance as well. This is why crystals are specified with an equivalent parallel loading capacitance. Use the same capacitance in circuit, and you will get nominal frequency within the stated accuracy. (Use the incorrect capacitance, or incorrect resonant mode -- crystals can be series and parallel resonant, with most oscillators using the parallel mode -- and you'll have some error.)
So, to some extent, you can deal with a low transconductance oscillator, by reducing the loading capacitors -- perhaps yours will work with 20, 15 or 10pF capacitors; but perhaps not 2.7pF, because it's just too little for the crystal you're using.
Most crystals have modest ESR, 50-100 ohms; as you can see, ST prefers somewhat higher, ca. 200 ohms, and these types specify smaller loading capacitors, which will give a higher network impedance, leading to more loop gain. Makes sense.
Don't forget to include pin and crystal holder capacitances -- the parallel equivalent capacitance equals the two terminal capacitances to ground, in series. That is, if you have two 20pF capacitances from either end of the crystal to ground, they act in series as the crystal sees it, for a total 10pF equivalent.
Also, by extension, very low frequency (tuning fork) crystals, typically use quite small capacitances to begin with (~5pF), and combined with the low frequency, they have quite high impedances indeed, 100s kohms. Keep this in mind when using one of these (e.g. for a RTC). They are sensitive to ambient noise, PCB contamination, etc.
for (int i = 0; i < 100000; i++)
asm("nop");
Do you have a blank board or a CAD drawing of the PC board to see where the crystal ends go?First post has layout pictures.
Did you by any chance do a connectivity/shorts test on that PCB? The printing looks awfully sloppy for TSSOP footprints...Yes, I think I've nearly worn out the continuity buzzer on my meter since I started manufacturing this PCB :) I've been super careful about shorts and opens and have tested the crap out of this board each time I make a change. I know that the printing looks sloppy (I've had to re-solder that IC multiple times) but I have made sure that every lead is wired to its trace and I've used an Xacto knife to etch grooves between some of the leads that had shorts in them.
And yeah, inline attachments is disabled while we figure out why they were corrupting. In the mean time, edit and embed a link to the attachment like so:Ahh got it. Thanks for the tip!
This is a very strange device. From the device datasheet I can't even tell what step actually enables the oscillator. There does not seem to be a defined "enable" bit. It looks like just the pin configuration does this. This is very strange.The actual power-up of the XTAL is accomplished by clearing bit 5 of PDRUNCFG (UM10601 section 4.6.32), after which it is expected for software to induce a 500us delay.
It looks like your oscillator tries to do something while VDD is still rising. Why is your VDD so slow?An excellent question. To find out, I first tried bypassing my 3v3 LDO and powering the MCU directly from my power supply but I saw the same slowness. I then suspected my 3.3uF bypass cap on the 3v3 side might be too large, so I desoldered it, but the waveform remained the same. Finally, I replaced my power supply (Keysight E36313A) with a square wave output from my signal generator and this time I saw a much tighter rise to Vdd, about 200us, as opposed to >40ms when using the power supply (wow! I had no idea that the slew time was so glacial on such an advanced power supply. What the crap, Keysight?).
I would add an empty delay loop at the very beginning of the program before the clock initialization:I've added the above delay and I'm toggling a GPIO as a marker to indicate start and end of clock init. Here are scope shots at increasing levels of magnification:Code: [Select]for (int i = 0; i < 100000; i++)
asm("nop");
Basically I want to see the crystal startup procedure when VDD is already stable.
And also, trigger on the XOUT, not VDD.
Wow, your board photo looks like both leads of the crystal are on the same copper land that goes all over the board.When manufacturing the PCB I cut to shape a layer of Kapton tape and stuck the crystal leads through it, so that there is an insulating film between the crystal body and the ground plane pour on the PCB. I've repeatedly tested to make sure that there is no conductivity through the layer.
I don't see an NXP logo on the part, is it from a reputable distributor? That looks like something from the gutters of guangdong.
I automatically get the creeps from that soulless laser etching with no manufacturer's logo... lots of pics showing one.I totally get why you got that impression. I did probably eight or 10 rounds of hot air reflow on this chip to get it correctly mounted without shorts/opens and it looks like the heat might have eroded some of the package text. In addition, I was using the ring light on my microscope to illuminate the board. These are genuine chips that I bought from DigiKey a while back and here's what they look like new and in different lighting:
The PCB layout is not great when you take ground-pours and have slices in them, and connect them on one end. It totally ruins them. Lack of vias just leaves islands that I am not a fan of. The very long trace from the MCU GND to the south end of the board, curling to J1-7 is not ideal. I don't think it's enough to upset the crystal oscillator but would it make the board unreliable wrt EMC.Roger that, definitely getting the message that my layout needs to be redone. I will be making a new version in the near future but I want to see if I can still get this one working right now.
I agree the VDD ramp up is way too slow. This is interesting:I believe this is what the 500us software delay is for. At any rate, I am seeing no indication that any oscillation is occurring whatsoever, so I don't think that more settling time would help in this case.
"8.20.5 Wake-up process
The LPC81xM begin operation at power-up by using the IRC as the clock source. This allows chip operation to resume quickly. If the SysOsc, the external clock source, or the PLL is needed by the application, software must enable these features and wait for them to stabilize before they are used as a clock source."
Thanks NXP for telling us how long that takes lol. I've seem 10's msec for xtal osc to startup.
OP could also try HF osc mode to increase gain.Great suggestion. I set bit 1 in SYSOSCCTRL and retried; no change, however.
After I/O pins init the XOUT goes to some strange level of 2.5 V.Yeah, the 3.3V->2.5V transitions happens when the Switch Matrix (SWM) is used to route the functionality of pins P0_8 and P0_9 to XTALIN and XTALOUT, respectively. At the time that this happens, the pull-up resistor is still activated (it gets disabled later in the sequence), and being an analog pin now with a lower operating point it doesn't surprise me that the reference high voltage is lower than 3.3V. This is just pure speculation on my part though.
It is also strange that XOUT went to 0 in a steady state. See what happens on the XIN at the same time.Here is a capture of XIN vs XOUT. Note that XIN was captured using a passive probe while XOUT was with an active probe.
And then try to drive XIN from the external source. Does XOUT show inverted waveform?I'm assuming you mean with an unpowered PCB. Here's what it looks like when I drive XIN with a 3.3V 12 MHz sine wave. I captured statistics for ~1k samples. The frequency and quality of the waveform vary quite widely, but I think that that's in large part due to my long injection leads causing significant inductance. I'm a bit surprised to see XOUT Vpp >9V though! I know that this is due to resonance, because setting my wavegen to 11.99MHz or 12.01MHz attenuated the signal by more than one order of magnitude. But I was not expecting the voltage to triple like that.
The driving experiment needs to be done with with the device powered. You don't need high frequency, a few kHz will work. You can also use a series resistor to limit the current.Ok, here are captures of XOUT on a powered PCB with the crystal still attached and 68pF load capacitors this time (from another failed attempt last night to get the board working):
Basically I want to check that inverter is actually working as an inverter and produces correct results.
Without the crystal XIN and XOUT should reach the same "middle" voltage. In your case it looks like XIN is pulled-up, so XOUT is 0, but the feedback resistor is not strong enough to override that pull-up. So may be try adding a stronger external feedback resistor to see what happens.
I would use thicker traces to the crystal portion. It's OK to have the caps right near the crystal pins and the ground-pour closer. You have it backed-off at the crystal pads but not at the test-points or capacitors, so what was the point. I always use ground-pour on MCU crystal traces and the pF it adds is not a problem.
The ground pour has some skinny slices which I never like, they wreck the whole concept. So I try to keep those two areas from being thin.
And then make the traces to the crystal as thick as you can, and still be prepared to solder the wire in top of them.Thanks guys, I've updated to v1.3.1:
After all this, I have to question the impedance of the Voltera conductive ink :-// What do we know about how it behaves at 12MHz and the Skin Effect? It might be the issue here.12 MHz is a low frequency relative to what Voltera ink can handle (https://community.voltera.io/t/using-the-v-one-for-rf (https://community.voltera.io/t/using-the-v-one-for-rf)). Also, doing our FRA and signal injection experiments above suggested to me that even my subpar layout performed adequately at that frequency. Or do you have a different interpretation?
The first thing to do is to measure the actual resistance of the track from the crystal pin to the MCU pin.
I should point out that I measured the resistance between each XTAL pin on the back of the PCB and the corresponding lead of the MCU on the front of the PCB, and I saw about 1.4 Ohms each. This seems quite high to me - might this be a significant issue, or is it low enough to be safe?
You can actually do that for the existing design - just double the tracks with thin wires. Use individual strands from the multi-stranded wire.I haven't tried this yet. I'll report back if this ends up fixing it, but I'm pretty doubtful at this point. I think I need to make a new board.
"As the {baking} ink temperature increases, chemical reactions are triggered and the metallic particles will form a conductive matrix and fuse together. Many conductivity and soldering problems occur because the ink was either not cured right away, at the right temperature, or long enough."I cured right away and used the default settings on the Voltera.
Copper rivets (https://www.voltera.io/support/working-with-rivets#main) for via's seem odd to mix with silver paste. Another connection to test, as how does ink do much on copper, I'm used to soldering.It seems to work ok for me and presumably for the majority of Voltera users. I do continuity tests on all vias and I add a little solder between the rivet and the trace if there's an open.
I would be curious of the (flux?) wash processFor hand soldering and reflow, I use minimal amounts of (nonconductive, no clean) ChipQuik SMD291. For all three sources of flux (the ChipQuik, rosin core in my hand solder, and the solder paste) I wipe away most of it with a Kimwipe and some 91% isopropanol.
measure leakage currents and capacitance between some trace runs, in case that is happening.Haven't done this yet but that will be my next step.
It's just that a new board would not really put us further ahead, whether it works or not, as to knowing what went wrong.I agree, I was just getting frustrated about getting nowhere with the old board and had also reworked it too many times for it to be viable. (Un)fortunately the new board seems to suffer from the same issue, so I can continue debugging on that.
The fact that Xout is squared is strange to me. Typically when oscillations are stable both Xin and Xout are closer to sine waves. Xout is a bit higher amplitude.No, sorry, perhaps my wording wasn't clear. XIN and XOUT were both sine waves. CLKOUT is the system clock output, which is a buffered copy of the internal system clock and consequently a square wave.
I don't know id this is some feature of the NXP oscillator or something else is wrong.
Can you make it start again? Can you capture Xin/Xout at the same time?
Or is CLKOUT a separate pin?It's an internal signal which I routed to a physical pin via the MCU's Switch Matrix (SWM).