Shop OBEX P1 Docs P2 Docs Learn Events
Crystal/PLL+ Prop issue? — Parallax Forums

Crystal/PLL+ Prop issue?

TymkrsTymkrs Posts: 539
edited 2014-10-12 15:29 in Propeller 1
Hi all,

Question! We designed a board with Prop1 (of course) and added a 5mHz crystal (as expected). Ran it through its paces and ran code on it and it was doing fine. However, after a couple of days of doing that, the code "stopped running". So we could still compile to the RAM and EEPROM, but the code wasn't doing what it was supposed to. So for example, we used a multimeter on a Prop pin to see if a 1/0 could be seen, and it couldn't.

We then switched out the crystal information with RCFast, and the code ran. We tried then to see what would happen if we ran it only with XTAL1 and it ran fine (or rather we could see voltage from the pin we measured) and as soon as we added any form of PLL to it, it stopped working. We also replaced the crystal just in case it was a malfunctioning crystal.

Has anyone else come across this issue before? Ie, what causes the phase lock loop on the chip to go bad?

Many thanks for any insight!
Addie

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-10-07 19:02
    Yours is a well-known symptom (i.e. PLL dies) of bad power distribution and/or inadequate bypassing, Please post a schematic and an image of your layout, and we will take a look at it.

    -Phil
  • Mike GreenMike Green Posts: 23,101
    edited 2014-10-07 19:42
    When there's inadequate power bypassing close to the chip and/or the power traces leading to different sides of the chip go by somewhat different paths of some length (large fractions of an inch say), there can be a transient voltage difference between two points on the Vdd or Vss busses on the chip. This can be enough to damage part of the chip. The PLL multiplexor happens to be the most vulnerable and first to blow.

    The best way to design this out is to copy one of Parallax's designs, at least as far as power distribution near the chip. You'll notice that there are at least two bypass capacitors very close to the chip, one on each side. The multiple Vdd pins and multiple Vss pins are each connected together, usually under the chip so the traces are very short.
  • TymkrsTymkrs Posts: 539
    edited 2014-10-08 14:57
    Hmm - here's a snapshot of the layout for the bypass caps. I have 0.1uf bypass caps on all 4 vdd/vss pairs and they're connected - power connected on the top layer, and ground connected on the bottom layer of the board.

    There's also a ground plane on the bottom of the board, but I've undone the fill for the sake of the picture.
    .
    Image1.png
    Image1.png
    809 x 630 - 39K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-10-08 16:59
    Tymkrs wrote: »
    Hmm - here's a snapshot of the layout for the bypass caps. I have 0.1uf bypass caps on all 4 vdd/vss pairs and they're connected - power connected on the top layer, and ground connected on the bottom layer of the board.

    There's also a ground plane on the bottom of the board, but I've undone the fill for the sake of the picture.
    .
    Image1.png

    Well that part looks fine then but the component in the top left hand corner has a +5V supply but a pin goes from there direct to the Prop which is a problem if the component is sending a 5V signal into a 3.3V Prop.
  • TymkrsTymkrs Posts: 539
    edited 2014-10-08 17:14
    Nope, that module's just listening for a signal from the Prop, not sending anything into it.

    Also a new oddity. When I run the code with just xtal1, the leds that I'm turning on and off are taking say 500ms to go through their cycle instead of the 10ms that I want it to go at. When I use RCT fast, the LEDs are going faster (as I expect)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-10-08 17:41
    Tymkrs wrote: »
    Nope, that module's just listening for a signal from the Prop, not sending anything into it.

    Also a new oddity. When I run the code with just xtal1, the leds that I'm turning on and off are taking say 500ms to go through their cycle instead of the 10ms that I want it to go at. When I use RCT fast, the LEDs are going faster (as I expect)

    That's a bit strange too. Looking at the crystal I have always said that these huge gull-wing HC49 crystals are just wrong, they really are a kludge adapted from a standard through-hole HC49 but bending out the leads turns them into big antennas and creates routing problems. So much easier and better to use proper SMD crystals (5x3mm etc) or even cheap oscillators which are very compact as you can see, but that's my take on things.

    .
    P8M composite.jpg


    Now anyway, I've gleaned enough info from your board to know what all the pins bar a couple are doing so the only other thing I don't know about is the regulator, if it's LDO it has to have the right cap on it's output, usually 10uF tant for it to remain stable. If it doesn't and it oscillates then you can rather large voltage swings. So at present I'm scratching my head too.
    P8M composite.jpg
    1023 x 899 - 683K
  • Hal AlbachHal Albach Posts: 747
    edited 2014-10-08 18:42
    Recently I had a Project Board USB exhibit similar conditions that you are having. Everything worked according to Hoyle while running under RCFast, but as soon as I selected the crystal for a clock source everything came to a screeching halt. Thought I had a bad crystal, tried some others I had laying around. None of them would work. Removed the crystal and ran the multi-led blinking program using just the PLL, program did run but hideously slow. Leds would come on and off in 3 - 4 minute intervals when it should have run infinitely. faster. It sort of seemed like the PLL was triggering on 60Hz from nearby sources. I had a 6 MHZ oscillator (the four legged kind) and connected it to the appropriate crystal pin and the prop came back to life on all cylinders. With the PLL set for x16 the program ran as expected - very fast.
    What I'm trying to get across is that the PLL may very well be your problem, or it could be the crystal driver in the prop that is not working, which was my case. However, given that you have a custom board made for this one, hanging an oscillator on it will be rather ugly and impractical.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-10-08 18:45
    While I do a few things different too to help with overclocking, I cannot see anything that would cause the PLL to die either.
    How did you solder the prop? Perhaps it got too hot???
    Have you tried a second board just in case???
  • jmgjmg Posts: 15,173
    edited 2014-10-08 19:46
    Hal Albach wrote: »
    .. I had a 6 MHZ oscillator (the four legged kind) and connected it to the appropriate crystal pin and the prop came back to life on all cylinders. With the PLL set for x16 the program ran as expected - very fast.

    Trying an external Osc is a quick and easy sanity check, and can confirm if the PLL is actually toast.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-10-08 19:54
    Tymkrs wrote:
    Also a new oddity. When I run the code with just xtal1, the leds that I'm turning on and off are taking say 500ms to go through their cycle instead of the 10ms that I want it to go at. When I use RCT fast, the LEDs are going faster (as I expect)
    That's a really good clue! It means your crystal is oscillating -- if at all -- at a much lower frequency than expected. As a consequence, its frequency is lower than 4 MHz, the lower limit for successful PLL driving, so the PLL is not able to lock.

    I would replace the crystal with another one. BTW, what's the part number of the crystal you are using?

    -Phil
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-10-08 21:35
    Phil Pilgrim (PhiPi) wrote: »
    That's a really good clue! It means your crystal is oscillating -- if at all -- at a much lower frequency than expected. As a consequence, its frequency is lower than 4 MHz, the lower limit for successful PLL driving, so the PLL is not able to lock.

    I would replace the crystal with another one. BTW, what's the part number of the crystal you are using?

    -Phil

    OP said in top post "We also replaced the crystal just in case it was a malfunctioning crystal."
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-10-09 00:35
    Peter Jakacki wrote:
    OP said in top post "We also replaced the crystal just in case it was a malfunctioning crystal."
    'Missed that, obviously, but still: the crystal is apparently not oscillating at 5 MHz. What would cause that? The wrong drive setting? Maybe XTAL1 is not appropriate for that particular crystal. A check of the XO pin with an oscilloscope would reveal a lot.

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-10-09 03:08
    You need an 18-20pF xtal. Maybe your xtals are quite different and therefore not oscillating correctly (as suggested).
  • TymkrsTymkrs Posts: 539
    edited 2014-10-09 12:29
    I'll have to get the specific part number when I get home, but it's a 20pF 5.0mHz crystal
  • TymkrsTymkrs Posts: 539
    edited 2014-10-09 12:32
    Oh here we go, found it: http://www.digikey.com/product-detail/en/ECS-50-20-5PX-TR/XC1265CT-ND/827729
  • jmgjmg Posts: 15,173
    edited 2014-10-09 12:39
    jmg wrote: »
    Trying an external Osc is a quick and easy sanity check, and can confirm if the PLL is actually toast.

    If you don't have a 5MHz Osc Module handy, but do have a spare Prop Board, you could output 5MHz to a pin on that, using a counter, and wire that to the suspect Prop, as an external osc equivalent.
    You can also run the same code in the suspect prop, and use a freq counter to check PLL operation, and no-pll cases are as-expected.
    What loads is this driving, and what sort of energies ?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-10-09 12:42
    That crystal should work fine. Check to make sure the affected leads on the Prop and on the crystal have good solder connections and that there are no hairline breaks in the traces leading to the crystal. I've seen intermittent problems resulting from both of these causes. Do you have an oscilloscope? Checking the XO output will tell you -- and us -- a lot about what's going on. Also, check to make sure that all of the Prop's power and ground leads have good solder connections. One bad connection there could destroy the PLL.

    -Phil
  • RaymanRayman Posts: 14,654
    edited 2014-10-09 12:55
    You probably already did this, but make sure you have good continuity between Prop xtal pins and the xtal...
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-10-09 19:29
    Agreed. That xtal should work. Perhaps you inadvertently destroyed the xtal osc / pll while probing - just a thought???

    Can you build another board???
  • LawsonLawson Posts: 870
    edited 2014-10-09 22:33
    If you're mixing 5v and 3.3v logic on the board and any of the 5v signals to the propeller idle at 5v it's pretty easy to pull the 3.3v rail higher. Most regulators won't sink excess current to hold a power rail down to the set point. (exceptions are some uA LDO's, reference regulators, and some switching power supplies) I've gotten caught by this one recently.

    I've also found that the Prop's XTAL oscillator to be touch sensitive. I've stopped it several times by poking at the wrong spot with my fingers. A power cycle has always re-started the crystal just fine though.
  • TymkrsTymkrs Posts: 539
    edited 2014-10-11 15:48
    We finally got some time today to do some probing around. We haven't tried an external oscillator just yet, but for sure something's wrong with the PLL as none of the code will run if we call it in the CON section.

    That said. We checked to make sure that the crystal was working and that there was good continuity between the xtal pins and xtal - and all was fine there.

    One of the items we're driving is a solenoid (prop pin to base of fet to solenoid), and while probing the 3.3v power line, we noticed that whenever the solenoid drew current, there was a voltage upspike, which is possibly what killed the pll. So we've added a massive cap between the 3.3v and ground and now when scoped, the voltage is nice and smooth.

    Whisker's currently putting on another prop chip so we'll see if that runs any better. Thanks to you guys for your help - we had no idea about the PLL issue before!

    Addie
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-10-11 16:02
    Tymkrs wrote: »
    We finally got some time today to do some probing around. We haven't tried an external oscillator just yet, but for sure something's wrong with the PLL as none of the code will run if we call it in the CON section.

    That said. We checked to make sure that the crystal was working and that there was good continuity between the xtal pins and xtal - and all was fine there.

    One of the items we're driving is a solenoid (prop pin to base of fet to solenoid), and while probing the 3.3v power line, we noticed that whenever the solenoid drew current, there was a voltage upspike, which is possibly what killed the pll. So we've added a massive cap between the 3.3v and ground and now when scoped, the voltage is nice and smooth.

    Whisker's currently putting on another prop chip so we'll see if that runs any better. Thanks to you guys for your help - we had no idea about the PLL issue before!

    Addie

    I suspected you had an inductor in there somewhere :)

    It's good practice to drive the MOSFET through a resistor even though it doesn't need it, it is mainly for protection for the Prop I/O as you can get a spike through the drain-gate capacitance or even to protect it in case of catastrophic failure. Also add a pulldown on the I/O side and this also acts as a voltage divider back into the I/O. I'd suggest 1K to 10K or more for the series resistor since it is only a solenoid and the pulldown could be the same.

    BTW, it's just as well the PLL suffers first as otherwise it could be almost anything, at least the Prop can limp along if it needs too. Tough little tyke it is.
  • RaymanRayman Posts: 14,654
    edited 2014-10-11 18:28
    yeah, solenoids and motors and such can all give you voltage spikes due to inductance: V=L*di/dt... If you try to switch off the current in an inductor, it will develop a voltage to fight back...

    I'd recommend using some kind of isolation between Prop and inductive load.
  • DomanikDomanik Posts: 233
    edited 2014-10-11 20:58
    Addie,
    Tymkrs wrote: »
    One of the items we're driving is a solenoid

    It's common practice to attach a diode across the coil to clamp the inductive kick. A collapsing magnetic field can induce significant voltage back into the coil driver device. It could be punching through your FET and into your prop. Depending on the bandwidth of your scope and the parasitic C of your circuit, you may not see the full extent of the transition.

    Dom...
  • RaymanRayman Posts: 14,654
    edited 2014-10-12 05:21
    This is true. I think it's often called a "free-wheeling diode". That might be enough.

    Still, personally, I'd use some kind of isolation to have the coil on a separate circuit.
    Could be relays, optoisolators. Transistor might be good enough as long as the power supply for the Prop is well isolated from the power supply for the coil.

    I think a Parallax board uses a 10uF inductor between the power for Prop and power for servos to provide some isolation.
    That plus the diode might be enough.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-10-12 05:48
    Rayman wrote: »
    This is true. I think it's often called a "free-wheeling diode". That might be enough.

    Still, personally, I'd use some kind of isolation to have the coil on a separate circuit.
    Could be relays, optoisolators. Transistor might be good enough as long as the power supply for the Prop is well isolated from the power supply for the coil.

    I think a Parallax board uses a 10uF inductor between the power for Prop and power for servos to provide some isolation.
    That plus the diode might be enough.

    By power you of course mean the bulk DC supply as I am aghast when I see solenoids and motors hooked up to the 5V supply or worse still, the Prop's 3.3V (oh, the humanity).

    Don't forget the series gate resistor, it's really important for a couple of different reasons and nothing to do with how BJTs are driven of course. The fact that the turn off is slowed down means it takes longer for the magnetic field to collapse thereby reduced the severity of the spike. Any "punch-through" back into the gate is limited by the series resistor and also the pulldown on the I/O side.
  • TymkrsTymkrs Posts: 539
    edited 2014-10-12 14:38
    Hi all,

    To address some of the suggestions brought up - I have a 10k resistor in series between the prop and the gate of the mosfet. And there is also a diode across the solenoid. The power supply for the prop is also fairly isolated from that of the solenoid's.

    We changed out the propeller, and it's working magnificently. So we might add the large bypass cap and see if that's enough.

    (We may also add in the pull down resistor, though before we had a pull up resistor and had to take it off for the solenoid to even work)

    Addie
  • jmgjmg Posts: 15,173
    edited 2014-10-12 15:29
    Tymkrs wrote: »
    We changed out the propeller, and it's working magnificently. So we might add the large bypass cap and see if that's enough.
    That does suggest it was stress damage to the PLL
    Tymkrs wrote: »
    To address some of the suggestions brought up - I have a 10k resistor in series between the prop and the gate of the mosfet. And there is also a diode across the solenoid. The power supply for the prop is also fairly isolated from that of the solenoid's.

    Was the spike most noticeable on Activate,or De-activate of the solenoid ? What current is the Solenoid ?

    What about the ground currents ?
    A 'fairly isolated' positive supply, does not guarantee safe ground paths.

    Turn-on of any inductive load tends to self-slew-limit due to the inductance, but turn off can generate a fast current edge, and the current path changes significantly from the FET source, to the Flywheel diode.
    Slowing down that turn off (with the large series Gate resistor) lowers the dI/dt of the edge.
Sign In or Register to comment.