Bad PLL?

Seairth

I inherited a PropStick USB at some point in the past. Today, I finally got around to using it, but couldn't get a basic hello world (blinking LED) program running. Eventually, I discovered that the problem appears to be with the PLL. If I set _clkmode to just xtal1, the LED blinks, but with any of the PLL modes, I get nothing. Before I toss this in the parts bin (I might still find a use for it at 5MHz), is there anything I can do to make sure this isn't really a bad PLL?

Edit: I also just tried switching out the crystal in case the PLL was having difficulty getting a lock. Interestingly, I did briefly get a blink, but the timing was very wrong and the net result is a full lockup. The fact that I did get something makes me think the PLL isn't locking (or holding the lock).

Yanomani

Since it uses a QFN part, have you also rulled out any bad solder joint(s) at the XI/XO pins (28/29)?

If not a bad solder joint, perhaps one of them could has suffered from some zapping (ESD) damage.

It it was XO that was dammaged, there is hope.

Having an available (spare) external 5MHz clock source (3.3V compatible) will help, but you'll need to reprogram the CLK register, for it to be compatible with an external clock source.

Erlend

I had exactly the same problem some time ago - after I had miswired and somehow fizzled the propeller; it continued to work, but only at the non-pll frequency. Tried to swap the crystal for a new one, but that did not help. Maybe it does for you, though.
Erlend

VonSzarvas

Another approach... does adding a couple bypass caps across the module help? Looks like there's only 2 onboard decoupling caps around the Propeller.

Seairth

So, I tried the following:

* switch out the crystal with a known good one. No change.
* bypassed the onboard regulator and supplied Vdd directly. No change.
* fed 7.5V to VIN (instead of the minimum 5V I was using). No change.

I did not try decoupling caps only because I don't have any on hand at the moment. However, I did take a look at Vdd with my propscope and it looks pretty clean.

I think it's safe to say that the PLL's shot. Time to label, toss in the bin, and move on. Thanks for the suggestions, all!

ErNa

I have to say, I never experienced a broken PLL, so may be, what we see are just alternative facts and we better just ignore those fakes? If we don't care, the P might work anyway? If not, it may be a good idea to establish tariffs for all faster processors, so we see no disadvantage? Just a brain storm coming over me, inspired by twitter!

Hal Albach

My first Project Board USB had similar problems, was told by support that the PLL was bad. When ever I would invoke a PLL mode the Propeller would run extremely slow. Tried other crystals, no change. It seemed that the crystal was just not running, possibly a bad crystal drive. On a hunch I connected a 6 MHz crystal oscillator - the 4 legged kind - and the Prop took off in high gear. All PLL modes worked perfectly. My guess was that with just a crystal attached the PLL was not seeing anything except possibly local AC hum? Anyway, using the self driving oscillator fixed the issue.

jmg

Hal Albach wrote: »

My first Project Board USB had similar problems, was told by support that the PLL was bad. When ever I would invoke a PLL mode the Propeller would run extremely slow. Tried other crystals, no change. It seemed that the crystal was just not running, possibly a bad crystal drive. On a hunch I connected a 6 MHz crystal oscillator - the 4 legged kind - and the Prop took off in high gear. All PLL modes worked perfectly. My guess was that with just a crystal attached the PLL was not seeing anything except possibly local AC hum? Anyway, using the self driving oscillator fixed the issue.

Interesting, the PLL side is a known sensitivity, but maybe the Xtal feed is what is damaged and an external square wave is enough to overcome that ?
FLiP uses a MEMS oscillator, tho mainly to save PCB space.

Rayman

Yes, the PLL is often the first thing to break when a Prop chip is abused.