Crystals vs Internal Oscillator

[Micrathene]

Does anyone have ideas on how sensitve the prop is to crystal type and placement?

In a previous thread I asked questions about breadboaring up a basic prop kit, and that all worked well - but now I'm adding a crystal to it, because basically everything on the object exchange looks like it needs the standard 80MHz setup.

Using the standard ConstantBlinkRate LED demo, straight from the propeller education examples, and varying the clock setup between RCFAST/RCSLOW and the various PPL options, I have massively different results. Everything functions more or less as expected using the internal oscillators, and any innaccuracy in 1hz blinking is understandable due to the tolerances of the internal oscillators. What confused me is that when using the external crystal put through a 4x PLL, the LED will come on...... and remain on for a few minutes, and then go off again, and repeat like that. The 8x multiplier makes this cycle take place more slowly (rather than more quickly, as you would expect) - and with the full 16x PLL - the LED never comes on. Despite the fact that the circuit works just as expected when the prop is operating on the internal oscillators. The crystal I used is normal 5MHz one from http://www.bitsbox.co.uk/crystals.html. I've read about load capacitance or whatever for the Prop, but sort of assumed it was not too too significat, and that it would only matter for overclocking or people who really cared - my logic was that if a specific type of crystal were necessary, it would have been more widely known.

Again, as a debugging aid, I tried to run a program which would put out some data over a serial port - I used the GPSFloatDemo from the object exchange for this (really awesome looking code by the way), but with the clock set to RCFAST - text came out over the serial port, but it was garbled. Can the prop not do accurate serial comms using the internal oscillators? But that can't work, as it's my understanding that the prop is in RCFAST mode to load spin off of the proptool.

Hopefully that made sense, and someone with greater knowledge of the arcane lore of high frequency crystals will be able to explain. As far as I know, my prop is properly decoupled with some small ceramic caps across both of the power pins (using the DIP40 version). The crystal is located as close as possible to the XI and XO ports of the prop (are crystals polarity sensitive when it comes to XI and XO)

Do these issues look solveable, or should I pack it in and buy a proper devboard? Trying to save a bit of money by breadboarding it out myself.

Specific issue, I know, but googling failed badly, and it is very frustratign to be so close to having everything working and ready to crank out some VGA, but failing at the last hurdle......

Thanks for reading!

[Mike Green]

1) The RCFAST clock is not accurate enough to use for serial I/O. I'm not surprised that you're getting garbled text when you attempt to use it. The download protocol uses a self-clocking mechanism where 9 of the 10 bits of a serial character cell (including the start bit) are used to send 3 bits of information with each 3 bits being %011 or %001. The RCFAST clock is stable enough that, once calibrated this way, it can communicate reliably for at least the time needed to download a program.

2) How about showing the actual code that you're using for the LED blinking. It sounds like the code may be causing the behavior you're seeing. If there was a problem with the crystal and oscillator, the Propeller wouldn't work at all with the system clock set to something other than RCFAST or RCSLOW.

3) Crystals are not polarity sensitive.

[HollyMinkowski]

With the prop you just have to use a crystal to do anything other
than a trivial LED blink program.

propeller chip + xtal + eeprom chip = the minimal setup for anything serious.
This basic setup will run you about 9.25 or 7.25 in really large quantity.
....not a bad price for eight 32 bit cores.

Some controllers have an internal oscillator that is within 1% accuracy and you
can manage to do some real work just with that. The propeller's internal oscillator is
useful mostly for shutting your project down into a very slow clocking mode to save
battery power while it waits for something like a button press to tell it
that it should crank back up to 80mhz to do some work. http://forums.parallax.com/images/smilies/smile.gif

Post Edited (HollyMinkowski) : 5/30/2010 3:59:33 PM GMT

[Micrathene]

Thanks! I was pretty sure the insufficient accuracy was the reason for the serial not working, but good to have it confirmed. Neat technique for compensating for the inaccuracy during the boot process though.

Any thoughts about "standard" crystals being sufficient, without worrying about load capacitance etc?

Below is the code:


CON

'' _xinfreq = 5_000_000
'' _clkmode = xtal1 + pll16x - never works
'' _clkmode = xtal1 + pll8x - at least the leds come on, and switch very slowly
'' _clkmode = xtal1 + pll4x - leds come on, and switch quite slowly

_clkmode = RCFAST
'' rcfast and rcslow both make it work as expected.
PUB LedOnOff
dira[15] := 1
DIRA[22] := 1
OUTA[15] := 1
OUTA[22] := 1
''I know this could be done better, but the basic idea was that at the start, both leds would come on to check that it was wired correctly etc.

waitcnt(clkfreq + cnt)

repeat

outa[15] := 1
OUTA[22] := 0
waitcnt(clkfreq+ cnt)
outa[15] := 0
OUTA[22] := 1
waitcnt(clkfreq+ cnt)

[Mike Green]

It ought to work with any of the crystal clock settings.

If the crystal setting is "off", usually what happens is that the capacitive load on the crystal is different from the load the crystal was manufactured for and the frequency will be "off", but not to the extent you're seeing. There is a "failure mode" caused by excess voltage across the chip, usually caused by using just one set of Vdd/Vss pins and inadequate bypassing in the face of electrical noise. This damages the PLL selector and the Propeller only works in RCFAST or RCSLOW mode. What you're observing is different. The only suggestion I have is to try another Propeller chip if you have it. Normally, the Propeller is quite robust and forgiving.

You might try calling Parallax Tech Support on Tuesday. Sometimes tackling this sort of thing over the phone works better than the slow back and forth of a forum.