Problem using xtal1 input

bratte

I have been going around in circles now for a few days regarding the external 5 Mhz oscillator input on the Propeller Proto Board.· I can succesfully run my program using the internal 12 Mhz oscillator, and with the xtal1 at the 5 Mhz rate.· However, when I attempt to use the PLL multiplier at any rate, i.e. PLL2x thorugh PLL16x, the program will not run past the CON block where I issue the _clkmode command.· Here is the statement I am trying to issue...


CON
··· _clkmode = xtal1 + pll16x··························
··· _xinfreq = 5_000_000


I have also noticed that none of the demo programs that ran previously work anymore if they contain a· _clkmode setting that uses the PLL multiplier.· I have checked my 5 Mhz oscillator input with a scope and it looks fine.· Anyone have any ideas?· Is it possible that just the PLL·portion of my chip no longer works?·

Thanks,

Brian···

Mike Green

I've heard one or two others mention this. You should call or e-mail Parallax Customer Support.

bratte

Mike,

I tried the customer support line. They told me to post my issue in this forum. The individual I spoke with did not have much knowledge on the Propeller chip. Maybe I will call again today and see if I can talk to someone that has some knowledge in this area.

Paul Baker

You said that the demos used to work and they no longer do? What Propeller setup do you own?

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

Parallax, Inc.

bratte

Paul,

I am running the Propeller Proto Board setup, with the accessory kit installed (VGA, Mouse, KB). The demos that use the PLL setting used to work fine, and they no longer run. Anything that requires the use of the PLL does not work. Using the XTAL1 input at the non-PLL setting of 5 Mhz works fine, however. I am currently continuing work on my project using the internal 12 Mhz clock, but really need the speed and stability of the external OSC with PLL for some of my functions.

Chris Savage

Bratte,

Contact me (phone) in Tech Support and I will get this taken care of. Take care.

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

Paul Baker

Ok, we would like to get our hands on that board in order to diagnose it, please call tech support and they will issue an RMA. Do you think you can unsolder the accessory kit (mainly the big connector), our supply of the accessory kit was on the low side the last time I checked, and I want to make sure you'll have one availible to put it in the new board we send you.

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

Parallax, Inc.

cgracey

Bratte,

Sorry for the trouble. I have heard of three such cases, now, where the crystal oscillator works, but the PLL quit.·These failures might be indicative of·a design problem, so we·are anxious to·analyze the Propeller on your board, along with·a Propeller we got back from another customer who had the same problem with his PropStick.

I have no idea what could be causing these failures, but we'll go about dividing the problem in half until we locate the point(s) of failure. If there turns out to be a common failure point, then we certainly·have a design problem which will need fixing. Meanwhile, we'll review the layout for potentially inadequate·current paths within the PLL block.

Has anyone out there had a problem where video quit working? There are 17 identical PLLs on the chip, and video uses at least one within a cog.

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


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 3/20/2007 10:48:12 PM GMT

squidx

Looks like I belong in this forum, too! I have had 2 Dev Kits's video quit, and it does seem to be the PLL that's the problem. I'm sure that Parallax will figure out what the sensitivity is here. I'm wondering, if, since I need to run at the 16x5MHz external crystal frequency to use the video out, could I just get a crystal that is already at 80MHz? Or is that either a ridiculous crystal speed or something the Propeller can't handle? Or is there a way to make the video out work at 5Mhz?

Jeff Martin

Hi,

Yes, you can clock it at 80 MHz externally, however, you'll have to use a clock-oscillator pack because the Propeller's oscillator gain circuit doesn't have a setting for crystals in that range.

In case you're not familiar with them, a clock-oscillator pack (not sure if that's the official term) is a 4-pin chip that usually has a pin for power, a pin for ground,·an oscillator output pin, and a no-connect,...·you'll have to connect power and ground to the clock-oscillator pack and connect it's oscillator output to the XI pin of the Propeller.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Post Edited (Jeff Martin (Parallax)) : 3/28/2007 10:52:42 PM GMT

Chris Savage

A TTL Oscillator is what Jeff refers to. Any electronics distributor such as Jameco, Digi-Key or Mouser would have these. In fact, we carry a 75 MHz one at the following link.· Take care.

http://www.parallax.com/detail.asp?product_id=252-00005

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

squidx

Thanks for the info!

I'm not married to 80Mhz, it's just what I've been using. I'm wondering if anyone has attached any crystal/resonator > 20 to one of these PLL-disabled boards and gotten TV out by using XTAL2 or XTAL3 with no PLL multiplier...?

If anyone has done it, please weigh in!

Also, Jeff or Chris, if I do get a hold of a TTL oscillator, connect it to power, ground and XI, does that mean I don't connect *anything* to XO, and will the Propeller think that's weird?

Thanks,
Alex

bratte

For what it is worth, the replacement·Propeller Proto Board works great at the full 80 Mhz clock speed.· The old one is on it's way back for the Parallax gurus to have a look at.· Hopefully it will help them figure out why the PLLs are failing.· Thanks to all the people at Parallax, I was able to complete·a prototype unit·before my deadline.··Thanks for the great support!··

Paul Baker

Alex, the thing is that all crystals 25MHz or greater are designed to use the 3rd harmonic overtone (meaning the fundamental frequency is 1/3rd the stated frequency). Since the oscillator drive circuitry on the Propeller is a fundamental driver, you will only see that frequency. Also note that there is a range of frequencies that the PLL can handle on it's input side, namely 4MHz to 8 MHz (if you are operating at room tempurature you can go up to 10MHz), anything outside this range the PLL cannot lock onto.

You can use an external clock as supplied by a TTL oscillator, you just set the _clkmode to xinput, then the propeller will not be driving the XO pin. I advise that you use a 3.3V oscillator to avoid forward biasing the ESD diodes on the XI pin.

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

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/29/2007 2:15:59 PM GMT

Jeff Martin

Hi Alex,

That's right... with an external TTL oscillator, nothing is connected to XO, just to XI.· With a normal crystal or resonator, they will not run by themselves, they work basically on a symbiotic relationship where they "kick" on the XI pin, which goes through some oscillator gain circuitry inside the chip and then feeds back out of the chip and into the crystal via the XO pin... causing the crystal/resonator to kick again, and so on and so forth.· The TTL oscillator, is basically a crystal and oscillator gain circuit all built into one package... thus it needs power and ground and it provides an oscillating signal output.

As Paul said, you can set _clkmode to xinput and just connect the TTL Oscillator to the Propeller's XI pin and all should be well.

On another note:· I believe the TV object will not work below about 60 MHz or so... not positive about that... that is why you see 80 MHz being used (5 MHz crystal * 16x pll)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

squidx

So, let me see... It looks from the TV.spin documentation below, that if the frequency must be over 13,318,180. Does that mean that if I got an oscillator, either crystal or TTL, between 16 and 25 (per Paul's concern), that I should be able to run NTSC video?

Then if it's a regular crystal, I set _clkmode to the value of the crystal, and if it's TTL, I set _clkmode = xinput, or could I *always* do that (if I'm using an external oscillator rather than the internal 12Mhz) in order to avoid making errors?


'' bit 0 selects NTSC or PAL format
'' 0: NTSC
'' 3016 horizontal display ticks
'' 243 or 486 (interlaced) vertical display lines
'' CLKFREQ must be at least 14_318_180 (4 * 3_579_545 Hz)*
'' 1: PAL
'' 3692 horizontal display ticks
'' 286 or 572 (interlaced) vertical display lines
'' CLKFREQ must be at least 17_734_472 (4 * 4_433_618 Hz)*
''
'' * driver will disable itself while CLKFREQ is below requirement

Thanks to everyone for working hard on this problem!

Alex

cgracey

squidx said...

Thanks to everyone for working hard on this problem!

Well, we still need to get to the bottom of why the PLL has failed.
This morning we analyzed a returned PropStick which had this kind of PLL failure and we found that the actual PLL didn't fail, but it's digital feedback system did. We could see a current draw when we enabled the PLL, but it was as if DC was input into its reference, prohibiting oscillation. This same chip was taking about 800uA more than a healthy one should in sleep mode, so it seems it was damaged in some way, perhaps shorting some logic within the PLL feedback circuitry. If you could run those·current measurements·I pm'd you, that would help us determine if your chip(s) have suffered this same failure.

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


Chip Gracey
Parallax, Inc.

squidx

I agree that we need to get to the bottom of it. A replacement clock is just a workaround which might not even be reliable. I did those tests and private messaged them to you. Please let me know if they didn't arrive, and I'll send them again.

Alex

cgracey

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.

Post Edited (Chip Gracey (Parallax)) : 3/29/2007 11:36:39 PM GMT

squidx

Thanks for the investigation, Chip. I'm trying to figure out what to do to prevent these kinds of problem in my application (which has 3 motors, some transistor switching, relays and solenoids. The precautions I will be using are some fast diodes to ground on all pins in use, and increasing the physical separation of the prop from other components, and increasing the shielding around the components, especially the prop board.

Chip, do you have any sense of how fast these transitory current spikes might be? I'm wondering about using caps, chokes or ferrites if the frequency response would be appropriate.

Alex

QuattroRS4

Squidx,
I have built a number of industrial applications using the propeller - with 3phase high current inductive loads all in the same cabinet - it has contactors ,relays etc - it uses a common ground to the microcontroller supply rail - I had a few minor problems during prototyping - i.e. spurious resets, and similar - (it didn't damage any of the i.C's though) - always when a coil was collapsing and also because the prototype was on veroboard - however the finished control units used VFR303 series in line with outputs and VIN before regs..·(specialise to block inrush as shown in the attached pdf) as well as substantial ground planing on the finished PCB ... These have proved to be very successful

Also·use contact suppression across contactor / relay contacts (various iterations of these out there)·and cable routing is critical to minimise EMI .... some very interesting articles are abound about microcontollers in such environments..

In the meantime have a look at the attached pdf...

Rgds,
Quattro




Have a look at the various specs. attached PDF

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

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

QuattroRS4

I managed to dig out a couple of relevant documents - they make for some interesting reading ...

Rgds,
·······Quattro

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

squidx

Quattro -- that's *exactly* what I was looking for! I don't know how many hours of research you just saved me!

Thanks very much!

SquidX

QuattroRS4

No Problem ....

Regards,
Quattro

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