Problem using xtal1 input
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···
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···
Comments
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
Propeller Applications Engineer
Parallax, Inc.
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.
Contact me (phone) in Tech Support and I will get this taken care of. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
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
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
http://www.parallax.com/detail.asp?product_id=252-00005
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
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
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
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.
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
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.
Alex
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
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
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
Rgds,
·······Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Thanks very much!
SquidX
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'