Prop chip dies!

RichardF

I am the guy having PLL problems driving servos. I thought they had gone away when I rewired everything to eliminate the possibility of RFI causing the PLL to be erradic (is that a word?). It all seemed to work fine after that; then...· Last night while downloading from Prop Tool to EEPROM everything locked up, including my computer. After rebooting the computer, no mor PLL. I can use RCFAST, but nothinig with a crystal. I ordered a new chip so hopefully it will work and my PLL problems will disappear. I intend to send the bad chip back to Parallax for testing to see what was wrong.
Richard

Paul Baker

Richard, we know what generally causes the failure your are experiencing. Post your schematic and a picture of your wiring and we'll see if we can give you tips on how to keep this from happening again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

RichardF

Thanks Paul, will do.
Richard

Skogsgurra

I am more and more impressed with you guys!

Any other manufacturer would:

1 Not answer until asked many, many times.

2 Tell the customer that such a thing never happened before.

3 Tell the customer to check his wiring, his power supply, his mental state and a few other things.

4 Have no idea what happened.

5 Not offer any help - at least not without asking a bundle for it.

You are really different! And good.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

RichardF

Paul,

Here are pictures of my Prop-Bot circuitry. The yellow battery pack is a 4-cell NiCd connected directly to the PE supplied 3.3V regulator. Please inform me if you see something I shouldn't be doing.

Thanks,

Richard

RichardF

Paul,

Here is another picture with more detail. I used MS Paint as suggested.

Richard

Skogsgurra

Except for some decoupling capacitors across Vcc/Gnd and short jumpers to keep the Gnd points and Vcc points together, I do not see anything in particular. Use something like 68 or 100 nF for decoupling.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Paul Baker

Ok, here's the list of what I see as potential problems:

• The power from the batteries is way too circuitous, you have it running through a servo that doesn't even seem to be used
• Where is the wire plugged into the centerboard L2 going? If it's going to the outer rail ground, where is the right middle ground connected to the supply? Your power-in cable is blocking that area, but if it isn't connected, that means it's being supplied through the Propeller and thats a big no-no.
• Where's the input cpacitor for your voltage regulator? With that long of an input line the input capacitor is mandatory.
• If you want to play it safe, a system with servos should have it's a dedicated·supply for the servos where you tie the grounds together, this can greatly improve noise in the system.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

RichardF

Paul, please look at picture 004. The left outer rail is Vcc @ 4.8V and the right outer rail is Vdd @ 3.3V. I am supplying Vcc and the 3.3V regulator input from the same battery. There is no unused servo, you may be seeing just part of the battery switch. I will place 1000uf and 100nf caps across the input to the voltage regulator, as suggested. The circuit is identical to the PE circuit diagram in the kit, except for omitting the 5V regulator. The right middle ground is there, the capacitor covers it up. Servos are fed off of Vcc. I hate to use two separate supplies for the servos and chip, but if you feel that will prevent future problems I will certainly do it.
Thanks for the help, the new chip should arrive shortly. I will be extremely careful about static issues and keep my wiring short.
Richard

Paul Baker

Ah, so it is a switch. Ok, the last two things I can recommend, the first is to rewire the ground lead for left power rail so it hooks directly into where you bring the ground for your battery in. This will reduce the likelyhood of the return path going through any component. You should also consider putting a 1000uF cap across the 4.8V rail in the upper left right near where the servos are connected. This will serve as a local bypass for your servos and should help keep electrical noise from affecting the Propeller. Also it never hurts to locally bypass the Propeller, put the 100nF in 19B and 22B right next to the Propeller then bend it away slightly so the leads dont contact the oscillator.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

RichardF

I will do all of that.
Thanks,Paul
Richard

Bergamot

I'm having a similar problem; programs act screwy when a PLL is specified, but work fine at straight crystal frequencies.

The attached diagram is an accurate representation of my current layout, but I've had other layouts in the past, and one of them may have fried something.



Post Edited (Bergamot) : 6/14/2007 3:42:51 AM GMT

Paul Baker

Bergamot, your description sounds more like you need a bypass cap near the Propeller. I could be wrong but I think the PLL failure prevents the crystal being used at all, I'll verify whether I am correct tomorrow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

RichardF

Bergamot, what did you use to make your breadboard drawing? I sure like it.
Richard

Chris Savage

In previous cases believed to be PLL failures, the PLL appeared to be functioning normally. The problem was that the clock signal wasn’t getting from the PLL to the hub. This narrows down the problem to a path somewhere but in the above mentioned cases the RCSLOW/RCFAST seems to work. This would also seem to indicate that the clock switcher works. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Whit

RichardF said...
Bergamot, what did you use to make your breadboard drawing? I sure like it.
Richard

Bergamot,

·I will second Richard's comment. I would love to know how you made that breadboard drawning.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+


"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney

Bergamot

RichardF said...
Bergamot, what did you use to make your breadboard drawing? I sure like it.
Richard

An old version of Photoshop.

Mainly because I'm faster in that than anywhere else.

Paul Baker

Bergamot said...
I'm having a similar problem; programs act screwy when a PLL is specified, but work fine at straight crystal frequencies.

So what do you mean by screwy, do you get any response at all, or is it just dead?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

RichardF

Paul,
This is sounding familiar. I know what screwy means.
Richard

RichardF

Bergamot,
I don't think I was careful enough about static protection when I handled the Prop chip. You can bet I will be when the new one arrives. I am fishing for something you and I may have in common. Believe me I know what "acting screwy" means. Have you been running servos? There is a lot of RFI being generated inside those babies and it may be what got to my PLL. I will be using lots of capacitor protection to prevent that in the future.
Richard

Bergamot

No servos (yet), but like I said earlier, if it turns out I fried the Propeller, I won't be surprised and I certainly won't blame Parallax; it's a testament to the stability of the Propeller that I didn't fry it months ago, given some of the stupid electrical mistakes I've caught [noparse]:)[/noparse]

Mainly, I just want to locate the problem, and see what I can do to make sure it doesn't happen again. If I need to change my layout, or reorder replacement components, no big deal.

Paul Baker

Can you explain screwy, Richard may understand exactly what you mean, but I don't. Do you get some strange execution out of it or does it just sit there?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Bergamot

In the tests I've run so far, it seems to run with PLL enabled, but really slowly. I'll know for sure tonight.

Bergamot

Ehh, scratch that. With this code it does not seem to run at all:

_clkmode        = xtal1 + pll16x           ' Feedback and PLL multiplier
  _xinfreq        = 5_000_000                ' External oscillator = 5 MHz

but with this code it works fine (albeit at only 5mhz, which is fine for my needs as long as nothing else is wrong):

_clkmode        = xtal1                       ' Feedback and PLL multiplier
  _xinfreq        = 5_000_000                ' External oscillator = 5 MHz

Mike Green

Bergamot,
Thanks for the sample. What you're describing is probably the PLL failure that's been noted before. The clock works, but any PLL multiplier prevents the program from working because the clock can't get from the PLL to the HUB. The RC oscillator works and I believe the direct clock input works as you've observed. Others (Chris and Paul) have described this as a failure point when the chip is subjected to voltage spikes or noise beyond its ratings. Good filtering on the power supply lines and rerouting of noisy high-power wiring away from the chip and its connections should help.

RichardF

Mike and Paul
I am the originator of this thread and I am going add more confusion to the issue of PLL failure. I rewired and added capacitors and resistors as Paul suggested. Any wiring associated with the servos are several inches away from the chip. I have 100nf caps at each servo connection to the board and at the two 3.3v pins on the chip. I have a 1000uf cap where my battery power enters.

I received my new chip today and was meticulous in preventing static damage (wristband,etc.). I installed the chip on my board and started testing. Here are the results:

LED blink timing test shows 1 second cycle for all clock modes using 5Mhz crystal and using a crystal + PLL..x. My timing is done using waitcn(clkfreq/2 + cnt). This is good news.

Servo test was bad news! Servo positions change significantly with clock modes. Servo RPM for continous rotation servos (bot wheels) changes with clock mode. Timing for pulses is done using the same method as LED blink test. In RCFAST (12Mhz RC osc) servos are stopped with waitcnt(clkfreq/668+cnt), in xtal1 + pll1x a clkfreq/890 stops the servos! For 16x the timing is back to clkfreq/664. x4 and x8 are all different also.

I can press ahead with my projects using a set oscillator speed, but I have a feeling my PLL is going to die again as before. I am not sure what to do. Paul suggested a separate power supply for the servos and chip with a common ground. Maybe that is the answer but to me it is kind of a tomahawk engineering approach.

Appreciate any suggestions,
Richard

Bergamot

Does the BS2 library use assembly or spin for its pulse output timing? I'm not sure spin is granular or predictable enough for reliable pulse timing.

Andy Lindsay (Parallax)

Hi RichardF,

Let's rule out coding issues. Attached is some code (Test Two Servos.zip) I tested for holding the center pulse duration on my PEKbot (drives two Parallax Continuous Rotation Servos). I set the I/O pins to P16 and P18 with the help of the pictures you posted earlier. Try it out, and let me know if the center pulse duration still varies when you change the PLL multiplier. It shouldn't unless you use one of the RC modes.

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Post Edited (Andy Lindsay (Parallax)) : 6/15/2007 5:40:23 PM GMT

Andy Lindsay (Parallax)

Bergamot,

I can't answer for the BS2 library, but you can use spin to control pulse duration with accuracy down to the 80 MHz clock tick (12.5 ns). See the Counter Modules and Circuit Applications PE Kit Lab for details. The Test Two Servos object above is using the approach introduced in that PE Kit Lab. Once I get the comments and variable names adjusted, the modified version of the archive above will become part of that lab.

PE Kit Labs
http://forums.parallax.com/showthread.php?p=617192

Counter Modules and Circuit Applications
http://forums.parallax.com/attachment.php?attachmentid=0

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

rokicki

Please attach full code. If you attach the code I can run it on my bot and duplicate your results, or not.

RichardF

Andy,
I ran Test Two Servos.spin. Servos never stop, they run at the same speed (about 20 RPM) regardless of selected pll..x setting. The sweep isn't occuring, not sure I know why.
Richard

p.s. servo pins are 16 and 19