using phase lock multiplier with _CLKMODE locks up my propstick & RS232 serial
Dennis Ferron
Posts: 480
Hi,
I'm using the PropStick kit. Whenever I set any phase lock loop multiplier (even PLLx1) with my _CLKMODE, my propeller locks up. It works ok if I specify xtal1 for the mode and five MHz for the _xinfreq, but then the serial objects (both Simple_Serial and FullDuplexSerial) will only transmit ascii character 127. I'm only using 300 baud so even at 5MHz I think it should have worked. When I use the internal RCFAST clock, I can send serial but only up to 6 bits. (I can only send ascii 0 through 63; 64 and up have random errors in the higher bits.) I think that this is because the internal RC oscillator is not accurate enough to do RS-232 and that the timing errors add up, so that the first few bits come out ok but each successive bit is off by more than the last. So I guess I need the crystal?
I hooked up a 100 MHz digital scope to the XO and XI pins on the Propeller, and I am getting a clean 4.99989 MHz square wave (EDIT: I meant to say it is a SINE wave, not square wave) on both sides of the crystal (XO and XI). So I think that the problem must be either with the PLL circuitry inside my Propeller chip, or with my software. Can someone tell me what is wrong? Do I need to ask Parallax for a replacement Propeller chip?
Here is the source code I'm using that sends only ascii 127 (I'm receiving it on hyperterminal, 300 baud, no parity, 2 stop bits, tried with 7 and 8 data bits)(if I uncomment the '+ PLL1X or make it PLL<any>X, my propeller locks up completely):
I'm using the PropStick kit. Whenever I set any phase lock loop multiplier (even PLLx1) with my _CLKMODE, my propeller locks up. It works ok if I specify xtal1 for the mode and five MHz for the _xinfreq, but then the serial objects (both Simple_Serial and FullDuplexSerial) will only transmit ascii character 127. I'm only using 300 baud so even at 5MHz I think it should have worked. When I use the internal RCFAST clock, I can send serial but only up to 6 bits. (I can only send ascii 0 through 63; 64 and up have random errors in the higher bits.) I think that this is because the internal RC oscillator is not accurate enough to do RS-232 and that the timing errors add up, so that the first few bits come out ok but each successive bit is off by more than the last. So I guess I need the crystal?
I hooked up a 100 MHz digital scope to the XO and XI pins on the Propeller, and I am getting a clean 4.99989 MHz square wave (EDIT: I meant to say it is a SINE wave, not square wave) on both sides of the crystal (XO and XI). So I think that the problem must be either with the PLL circuitry inside my Propeller chip, or with my software. Can someone tell me what is wrong? Do I need to ask Parallax for a replacement Propeller chip?
Here is the source code I'm using that sends only ascii 127 (I'm receiving it on hyperterminal, 300 baud, no parity, 2 stop bits, tried with 7 and 8 data bits)(if I uncomment the '+ PLL1X or make it PLL<any>X, my propeller locks up completely):
CON
_clkmode = xtal1 '+ pll1x
_xinfreq = 5_000_000
STAT_LED = 22
OBJ
serial : "FullDuplexSerial"
PUB start | i
DirA[noparse][[/noparse]STAT_LED]~~
serial.start(31, 30, 0, 300)
repeat
repeat i from 1 to 100
serial.tx(i)
waitcnt(3_000_000 + cnt)
!OutA[noparse][[/noparse]STAT_LED]
Comments
I tried your program both ways on my PropSTICK and it worked fine. But I used Parallax's pBASIC debug window instead of the evil HyperTerminal. I would urge you to do the same before requesting a replacement chip.
-Phil
What I mean by the phase lock loop locking up the chip is that any program which attempts to set the PLL multiplier locks up; sometimes it resets the chip after a few seconds. Even programs which just blink the LED do this. That wouldn't be affected by hyperterminal.