PLL Burnout

crgwbr

Like most propeller projects, I'm currently doing a project that that uses the _clkmode = xtal1 + pll16x command.· However, one day, I noticed that it started to only work with _clkmode = xtal1 or _clkmode = RCFAST.· The pll comands stopped working completely.· Any idea why·it stopped working?

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

Oooh - thats a few posts I have read about this - what was the prop connected to in this project Craig ?


Do you have any pics of the prop circuit and associated hardware used ?
Did you read this thread ?

http://forums.parallax.com/showthread.php?p=639324

Sorry for all the questions but I'd love to know what is causing this - so as to definitely protect against it ...

Regards,
·········· Quattro



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/4/2007 12:55:20 PM GMT

Peter Jakacki

Crystals aren't logic gates, they are far more finicky and delicate. Without going into it too far have you tried changing the crystal? If you are soldering the crystal make sure you don't overdo the soldering bit. Also be aware that the residue flux can and will cause a problem as it is slightly conductive and this is more than enough to affect a crystal oscillator.

If this is a home-brew board just make sure your leads are as short as possible, like don't have the crystal sitting in a convenient socket a few inches from the prop.

*Peter*

QuattroRS4

Peter,
I agree with you there on all points - but thats a few such PLL failures I have read about - on Proto Boards etc .. there's more to this I think..

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Peter Jakacki

Quattro, to say that the PLL "fails" (silicon?) and not to consider the stressed vibrating quartz rock first would be plain ludicrous. I am just saying that we should always look for the simplest reasons first and eliminate them early on before tackling much harder explanations.

Depending upon the design of the PLL it could be rather sensitive to noise or harmonics. Crystal ain't crystals and depending upon the manufacturer, batch, handling, age, circuit, etc the performance and operation can vary wildly.

If anyone has an oscillator problem then the very first thing that should be checked is the crystal and the physical circuit. Preferably try another brand crystal in case there is a batch problem. A crystal that works perfectly well in one type of circuit may not in another type of circuit. There are $5+ crystals and seemingly identical 50c crystals, what's the catch? Most of the time the 50c one is fine, most of the time.

Craig, go through the checklist mentioned earlier and always cross-check if anything changes by reverting back and checking just in case it was a bad solder joint or something.

*Peter*

QuattroRS4

Peter,
As per previous post ...... there is of course the obvious checks - crystal or oscillator and connections etc.... - however this has popped up as a 'silicon failure' on a number of occasions which could be a concern in terms of application 'best practices' when connecting devices etc .... with a number of damaged props the first point of failure has been PLL (and where the crystal oscillator still works) - as described in the link in my earlier post -... this can't be ignored - we'll have to wait for feedback from Craig to see...




in the post I supplied earlier ...

Chip Gracey said...
SOME NEWS ABOUT PLL FAILURES:

We accidentally created one of these PLL-failure cases today by connecting power backwards to a Propeller system. It seems the reverse current destroyed part of the chip, resulting in excess current draw, and the main PLL was no longer functional.

From what I can tell, these PLL failures experienced by customers have mostly (if not all) been due to some type of current spike on VSS/VDD, or possibly on an I/O pin. All of the failures that I'm aware of have occurred on systems where some high-current switching was taking place on what was likely a shared ground, or there was some possibility of a ground loop between systems. There's not much any chip can do to protect itself from an over current event, but it is rather curious that the PLL seems to routinely fail on the Propeller. In every case I've seen, the chips drew excessive current after failure, aside from the PLL not working anymore. The only thing that I can think of to explain why the PLL dies is that maybe there is something about the VSS/VDD wiring within the Propeller chip that leaves the PLL logic slightly more vulnerable than other circuitry to an over-current event. If that's the case, a change in wiring might just shift the failure point elsewhere, but something is bound to fail whenever a large inrush of current occurs. It's much more important to stop those events from occuring, in the first place, by careful application.

Any time high currents are being switched, like in motor driving, you have to be careful to keep your microcontroller system out of the current path. It is not always apparent that your system is at risk. Even relays can wreak havoc when their fields collapse. This has been a problem with BASIC Stamps, SX chips, and now the Propeller. It's a problem with any low-voltage IC device. In the case of the Propeller, though, the PLL seems to be the first point of failure. I am going to go over the layout carefully to see if anything can be beefed up, but I doubt a wiring change would result in anything more than a slight upping of over-current tolerance, and would otherwise only shift the likely failure point to some other part of the chip. The only real remedy for this type of problem is careful application design that ensures the microcontroller is kept out of ground loops and away from current spikes. Even current spikes on nearby wiring can inductively couple into microcontroller signals, leaving a system vulnerable.

---

Chip Gracey
Parallax, Inc.

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/4/2007 1:26:29 PM GMT

Peter Jakacki

Quattro, I just find that in a great many cases that the obvious checks are not done or are done improperly because it "won't be that". I stick to my recommendations, silicon is silicon, it would be highly unlikely that it fails in this manner. In any case when the boys get their hands on some offending boards it will be the final say on the matter (I bet my money on the boards [noparse]:)[/noparse] ).

BTW, how many complicated and mysterious problems have we seen on this forum alone that have turned out to be simple simple problems that have been missed because the simplest checks were not carried out properly. Too many!!!!

*Peter*

Peter Jakacki

In regards to what Chip had to say about the failures it is obvious that this is not something that just happens and gee it is not surprising that something fails when the chip is reverse spiked. On a properly designed board there should never be a problem. If I zap a chip on a protoboard it is my problem, not the chip designers. Sure, they can make it more resistant but they can never goof proof it ever.


*Peter*

bambino

As you said Peter, there are proper ways to troublshoot a circuit, but I think that in the back of all our minds we see the worst every time the Power Led FADES A LITTLE!

Either way we need to see some more input than just my PLL quit working!

QuattroRS4

Peter,

With regards to·misconfiguring the I.C supply - agreed that is a scenario that is beyond the remit of any IC manufacturer - that is not really my point of interest in this whole matter - interesting point about that scenario, though, is the point of failure - PLL.
·The aspect of this 'problem' that does interest me though is the 'current inrush' - e.g.·back emf generated by an inductive load and also the ground loop aspects·...

I agree wholeheatedly with what you are saying .. Based on the few posts regarding this issue - I ran some destructive tests - the results of which were sent to Chip - whereby inrush current as a result of switching inductive loads repeatedly emulated the same said issue - oscillator fine PLL not working .. I then fitted filters VRF303 series and ran the same tests - without issue.. That is not to say that these tests were definitive but rather the issue can be emulated to a certain degree . Also there will of course be some props more prone than others as is the nature of IC manufacture..

Yeah I have seen the DOH ..... scenario - a simple solution to a puzzling problem..

and Yeah - and I bet the Prop and Boards are fine but at least this will lead to warnings and procedures being put in place to avoid such issues . I have many props in industrial applications running 24/7 switching inductive loads etc - without issue - PCB's with Ground Planing,filters,suppression on contacts etc - but all derived from a 'prototyping'·process as with Craigs current issue ..

P.S - Before I forget - saw your prop board on another post - nice job !

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/4/2007 2:02:05 PM GMT

crgwbr

Sorry I didn't reply sooner, I've been out of my office.· Anyway, I did notice that the power LED on pcb dimmed a little and then brittened a few minutes before I noticed that the pll was gone.· I trhink this was a problem with an encoder I was using (reversed polarity·to it).· This probable caused·a current spike on the main power busses.· The crystal is roughly 0.75 inches away from the prop, this is as close as I could possible put it, but I don't think it was a problem with that, as it still works without the pll multiplier.· From previous posts, it seems that there have been a number of these pll falures.· Is there somthing in the design of the silicon that makes the pll extra supseptable to breaking?· I guess what I'm asking is, do you think that the prop is safe for industrial applications like this one?

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

Craig,
Absolutely yes is the answer but ,as with all, low voltage microcontrollers circuit design is critical.As I have previously mentioned - I have quite a few Propellers and Stamps in 24/7 industrial applications all with inductive loads pnuematic solenoids, relays, and contactors for high current 380 - 415v 3phase motors -
I have used filters in line with all outputs I have coil suppression on relays and contactors
and contact suppression on contacts, P.C.B's are heavily ground planed - not just to eliminate spikes upsetting the controller but also for CE certification - I don't want to be 'generating' noise either.

see attached apps:

This is a sample of one of the Prop apps:
video.google.com/videoplay?docid=-4731155379062352204&q=Parallax+propeller

This is a stamp based app:
video.google.com/videoplay?docid=-7703119114106288120

One from the 'food industry' - during prototyping/trials .
http://video.google.com/videoplay?docid=4421309128503441226

Craig - do you have a schematic or pictures or both of the app ?

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/5/2007 3:10:03 PM GMT

Phil Pilgrim (PhiPi)

Craig,

One thing that's very important is how your power is routed. If the Propeller and high-power devices must share a common ground, be sure to connect each via a single cable/trace to a common point right at the power supplies. Do not assume that ground connections can be made at random — even to a heavy ground plane. You don't want ground currents from other devices flowing through the Propeller's circuitry. Better still would be separate grounds and optical isolation.

Quattro,

Nice app, that ball counter! What kind of sensors did you use to detect them? Are the balls still channelized when they're counted?

-Phil

QuattroRS4

Phil,
Sensors are 'SICK' - polarized retro reflective. Interesting that you asked whether the balls are channelized - Yes they are - during prototyping and when the volume was high the balls would knock off each other - disrupting the count ..The sensors are slightly off centre to pick up the space between balls if they were on top of each other going through (i.e. if balls were touching each other going through and the sensor was centre then it would only 'see' 1 ball - hence off centre).The count is also very accurate - as was the requirement.The whole top section sensors included can be removed to set up for a different ball size. I have 8 of these counters at that site with - all different ball sizes - in case you were wondering what the balls are for - roll on deoderants mostly! The feed conveyor and dryer section are now controlled by the this unit - over temp means the ball will swell (they are hollow) and not fit through the grading grid..There is also a link to shop floor data collection system..

The stamp application shown - is controlling a· 'grinding' process - the machine has a 11Kw (approx 15hp)
380V ac main motor, a 3.75Kw(5hp) 380V ac·hydraulic pump system, pneumatics and 24V DC·control - and
there is a fair degree of filtering going on there for contactors etc .Used Siemens contactors and a Siemens SITOP PSU··- I have always found them reliable .There are 28 of these units - they look filthy but it is a wet grinding process that runs 24/7.

Regards,
Quattro

Screen Images of Latest Version Propeller·Based Ball Counter .... Link to Rework Station etc...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 8/2/2007 11:09:21 PM GMT

crgwbr

Thanks for the advise. Because this app isn't too demanding, I was able to run fine at 5 MHz, at least for the prototype. A far as high-power devices, the only one is a 12v 0.5A valve being triggered by a reed relay. The current spike was caused by a one time wiring mistake (I hope one time, lol). On the next one, I'll keep the ground stuff in mind.

Thanks,
Craig

P.S. On the same project, the program stores a few values in the EEprom for use next time it turns on. However, occasionally it seems to loose the info. Any Idea why? I realize that loading another program would wipe these values, this is a different issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

Its probably timing related - is this just at start up that it looks for this value ?

If so - I saw a routine by Mike Green which toggles pins before first read/write ...

ah - I eventually found it -

Mike Green said...

It may be that the Propeller boot loader leaves the EEPROM in an odd state and it needs to be reset prior to the first read or write. Try putting this in your initialization code:

outa[noparse][[/noparse]28] := 1 ' set SCL high
   dira[noparse][[/noparse]28] := 1
   dira[noparse][[/noparse]29] := 0 ' set SDA as input
   repeat 9 ' up to 9 cycles
     outa[noparse][[/noparse]28] := 0 ' put out a clock pulse
     outa[noparse][[/noparse]28] := 1
     if ina[noparse][[/noparse]29] ' if SDA is not high, repeat
       quit

Do be sure to clear "buffer" before reading it just to make sure it's read.
It may be that neither the write nor read is actually happening. Both
the i2cReadPage and i2cWritePage will return non-zero if an error
occurred and you could display a message if so.

Regards,
Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/6/2007 12:48:10 AM GMT

crgwbr

Quattro,
Thanks for the reply, but I'm afraid I don't understand. The prop reads the code from the eeprom at startup, about 1 second after it starts running the code, it reads 12 bytes from the eeprom. If you could, please just explain your reply a little more.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."

QuattroRS4

The first EEProm access after a reboot may leave the EEprom in an Odd state - to quote Mike Green.

So this routine runs a clock pulse (SCL) x 9 and repeats·if SDA is not·high - and hey presto problem solved - I have used it and it does work...

Is it the first read/write after a reboot that is causing your problem ?

Quattro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'

Post Edited (QuattroRS4) : 4/11/2007 2:45:27 AM GMT

crgwbr

I guess this could be the problem. Instead of all 6 WORD vars reading there proper values, they will read as 0. I seemed to of solved this problem by putting them in the second EEPROM I have on pins 0-1.

Thanks Again,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Microsoft: "You've got questions. We've got dancing paper clips."