Spin2 code not working for me
changed to different cro, 100 MHz sample, now get a better picture with more samples per cycle, either way, found a problem ?
from a crystal 25 MHz / 32 = 781250 HZ, , no PLL, solid, even output waveform
now 800000 HZ,
cro shows wrong frequency, first half cycle is short
Something went off-track with the waveforms generation.
Both screenshots say 1uS/DIV, both waveforms periods are about 6.4 uS-long, but, 781,250 Hz would lead to a period of 12.8 uS, and 800,000 Hz would hit 12.5 uS, thus, none seems to be showing the right timings.
@bigtreeman, please, would you mind posting the code used to generate them?
@bigtreeman said:
seems to compile and load, no pin response
if I change to
pinstart (53, P_NCO_FREQ + P_OE, 1, $200000)
gives 200 khz out pin 53 ?
no signal out
Grrr, yes... I see. It outputs a short burst of pulses and then shuts down. When the main function exits the cog is stopped. I thought this wouldn't matter as the smart pins normally run independent of cogs. But if cog0 stops it seems that the whole system shuts down. So the correct code should be
The endless repeat keeps the cog alive. Sorry, I haven't tested it stand-alone. Instead I've extracted that piece of code from a larger program.
$20000000 is the value for the smart pin Y register which sets the frequency. Y is added to a 32 bit accumulator each clock. Bit 31 of the accumulator becomes the output signal. So $20000000 means one cycle every 8 clocks and 22.5MHz = 180MHz / 8. $200000 would mean one cycle every 2048 clocks or 180MHz / 2048 = 87.9kHz.
@ManAtWork said:
...
The endless repeat keeps the cog alive. Sorry, I haven't tested it stand-alone. Instead I've extracted that piece of code from a larger program.
Tripped on that myself before. It's because that cog drops all DIRs when it shuts down. The smartpin still needs its DIR high to cycle.
It's been quiet here for a while. Can I summarize what results we got so far...
Bigtreeman has at least a stable clock output in post #32, no glitches or hickups visible
we still don't have a valid sequence how to switch to a PLL clock >25MHz in TAQOZ without loosing serial connection
I still have no feedback if the test from post #35 is successful or not.
If nobody reports any positive or negative results I'll test some ~10 boards to check if the oscillator runs well. If I don't find any problems I see the matter as settled if nobody can show a clear procedure of how to reproduce a problem.
Thanks evanh, schematics work for me, I've been doing a bit of reading source and documentation.
spin2 is ok, some of my snippets are working, Taqoz works better, been using forth since the 80's.
Working between propeller 2 instructions and taqoz pretty well answers most questions now.
Using the xtal and pll now gives a fairly steady clock.
backed up the rom taqoz and fudged FLASHBOOT.FTH, so now booting flash 115200, rcfast,
hand crafted assembler shoved into flash boot, not classy but quick and effective.
To get Taqoz from SD card running with Kiss+SD, I did:
Removed pulldown R4.
Got Taqoz.zip from https://forums.parallax.com/discussion/167868/taqoz-tachyon-forth-for-the-p2-boot-rom/p1, copied it onto a SD card.
Due to the 25MHz cristal, the baud rate is 1152000 ( = 921600 *25/20 ) .
PuTTY can switch a prop plug to this unusual baudrate. Now you can contact Taqoz on P2. :-)
CLKHZ is not a constant, but this word reads a long at 20 (decimal).
(Therefore "250,000,000 ‘ CLKHZ :=!" does not work here.)
There is in the source:
XIDIV = 1 ' crystal/osc input divider'
VCODIV = 1
CLKMUL = CPUHZ/(XIN/XIDIV)
CLKCFG = 1<<24+(XIDIV-1)<<18+(CLKMUL-1)<<8+((VCODIV-2)&$0F)<<4+PF15
Original value of CLKCFG is : $0100_09F8
This constant is located at 24decimal.
To get a system running at 200 MHz with crystal 25MHz:
$0100_07F8 24 !
200.000.000 20 !
25.000.000 16 !
BACKUP BIX
After booting the baud rate is 921600 as intended.
The modified bootfile is included.
@ManAtWork
Perhaps it would be good to include these steps into your Kiss manual?
The way VCODIV is used, it will only calculate the mode value correctly for VCODIV values 1 and 2. Note there is a general rule of VCO frequency itself must stay >= 100 MHz for good stability. Therefore that 200 MHz sysclock should be very stable.
Of note is the CLKCFG is missing the PLL clock select bits (%SS=%11). I presume Taqoz must add those bits itself.
Ah, I see that XIN there. I suspect that too is a system variable that can be runtime edited, right? That's something that is missing in both Pnut and the Flex suite.
pll to 100 mhz, baud rate to X4, cro on pin 53, 1 mhz steady
looking at the spin2 code for maintaining the system clock in a safe manner
with initial setting -
CON xinfreq = 25_000_000
_clkfreq = 200_000_000
having system variables -
clkmode The current clock mode, located at LONG[$40]. Initialized with the 'clkmode' value.
clkfreq The current clock frequency, located at LONG[$44]. Initialized with the 'clkfreq_' value.
then setting clock with
CLKSET(new_clkmode, new_clkfreq)
avoiding a potential clock glitch
Usually not much, the northern limit of surf on the east coast before the reef.
Nothing is isolated on the cost with our real estate market these days, but Agnes is
very civilised, just beautiful. Mostly 2-3 foot, dropped to 1-2 foot.
The natives are friendly and respect old surfers, no dropping in.
To get Taqoz from SD card running with Kiss+SD, I did:
Removed pulldown R4.
Got Taqoz.zip from https://forums.parallax.com/discussion/167868/taqoz-tachyon-forth-for-the-p2-boot-rom/p1, copied it onto a SD card.
Due to the 25MHz cristal, the baud rate is 1152000 ( = 921600 *25/20 ) .
PuTTY can switch a prop plug to this unusual baudrate. Now you can contact Taqoz on P2. :-)
CLKHZ is not a constant, but this word reads a long at 20 (decimal).
(Therefore "250,000,000 ‘ CLKHZ :=!" does not work here.)
There is in the source:
XIDIV = 1 ' crystal/osc input divider'
VCODIV = 1
CLKMUL = CPUHZ/(XIN/XIDIV)
CLKCFG = 1<<24+(XIDIV-1)<<18+(CLKMUL-1)<<8+((VCODIV-2)&$0F)<<4+PF15
Original value of CLKCFG is : $0100_09F8
This constant is located at 24decimal.
To get a system running at 200 MHz with crystal 25MHz:
$0100_07F8 24 !
200.000.000 20 !
25.000.000 16 !
BACKUP BIX
After booting the baud rate is 921600 as intended.
The modified bootfile is included.
@ManAtWork
Perhaps it would be good to include these steps into your Kiss manual?
I've been using this code and want to change those clocking settings then compile a new Taqoz image.
I have to correlate changes in 5 locations.
when I compile with flexprop I get an error which I don't understand
/home/colin/TAQOZ/taqoz-flash.spin2:235: error: syntax error, unexpected number
235 _BAUD long baud_rate
spin2 documentation talks about 2 system wide variables clkmode and clkfreq and are these also used by PASM ?
could we calculate sane values for xmode _XTALFREQ _XDIV _XMUL _XDIVP based on _xinfreq and _clkfreq ?
It seems we shouldn't rely on the default firmware, but compile from source for different hardware setups,
loading firmware is usually done during manufacture
Pnut/Proptool have the two runtime system variables (clkfreq and clkmode). Everything else is compile time, sadly. Most other build tools also support runtime terminal baud as well. But only Taqoz has XIN (crystal frequency). I'm keen to get that changed so that runtime recalibration using a system specified crystal frequency is officially supported with all build systems.
Spin2 uses $40 clkmode and $44 clkfreq
PASM can reference these locations
Taqoz uses the memory locations $40-$7f for the return stack
shuffling the stacks around could push lutfree to $90
and some other system variables could be shoved into $48-$4f
in taqoz.spin2 -
' Offsets in LUT for stacks and system variables
retstk = $000 ' 64 deep'
clkmode = $040
clkfreq = $044
baud_rate = $046
free $048 > $04f
brastk = $050 ' 3 longs for DO or FOR '
datstk = $060 ' 32 deep'
lpstk = $080 ' 3 longs for DO or FOR '
lutfree = $090
auxstk = $090
was -
' Offsets in LUT for stacks
datstk = $000 ' 32 deep'
lpstk = $020 ' 190705 combines loop and branch stack - always 3 longs for DO or FOR '
brastk = $030
retstk = $040 ' 64 deep'
lutfree = $080
auxstk = $080
' The LUT is essentially free from $80 onwards ' * if you don't use the auxstk ?
'' hubset #0 ' SWITCH TO RCFAST'
'' mov hr1,_CLKCFG
'' hubset hr1
'' waitx ##20_000_000/100 ' wait ~10ms for crystal+PLL to stabilize
'' or hr1,#xmode ' use PLL bits'
'' hubset hr1
with
hubset ##clkmode_ & !%11 'start crystal/PLL, stay in RCFAST
waitx ##20_000_000/100 'wait 10ms
hubset ##clkmode_ 'switch to crystal/PLL
TAQOZ# rdfreq . --- 180000000 ok
TAQOZ# rdmode .bin --- %00000001000000000000011011111000 ok
seems to be xtal, pll 175 mhz, rcfast mode ?
I can manually rewrite clkmode and rerun hubset ##clkmode_
A tad vague on the question being asked ... When running a compiled program, it has no interaction with Taqoz. It takes over the Propeller chip. Each program has its own build of what is where, there is no OS conventions. Hope this answers your question.
That's why I talk about Pnut and FlexSpin separately instead of Spin2 generally. They each have their own indepedant build environments, not decided by the language.
The convention I'm gunning for is the minimal of just having a set of named, and preferably maintained, run-time symbols. Their location is not as important as them just existing.
And the four symbols of the ROM Taqoz are exactly the ones I want: xinfreq, clkfreq, clkmode, baud(debug).
Okay, maybe I've got a solution for what I want without any extra conventions. It's always been there but I hadn't cottoned on to how it was meant to be used.
For programs that want to use the crystal frequency in run-time calculations, they should always define a top level constant for xinfreq or xtlfreq ...
EDIT: Pnut does need to use that run-time baud symbol for its debug baud instead of having its own. Actually, it's more the debug system not handling a new clkset() than the changing of debug baud. Clkset() was put in as a function because hubset() was tricky to use when wanting to change the sysclock frequency. Clkset() should also handle updating of debug system too.
@evanh said:
A tad vague on the question being asked ... When running a compiled program, it has no interaction with Taqoz. It takes over the Propeller chip. Each program has its own build of what is where, there is no OS conventions. Hope this answers your question.
That's why I talk about Pnut and FlexSpin separately instead of Spin2 generally. They each have their own indepedant build environments, not decided by the language.
this is a recompile of taqoz V2.8 using spin2 clock control conventions
taqoz is written in spin2 and PASM
@evanh said:
Okay, maybe I've got a solution for what I want without any extra conventions. It's always been there but I hadn't cottoned on to how it was meant to be used.
For programs that want to use the crystal frequency in run-time calculations, they should always define a top level constant for xinfreq or xtlfreq ...
EDIT: Pnut does need to use that run-time baud symbol for its debug baud instead of having its own. Actually, it's more the debug system not handling a new clkset() than the changing of debug baud. Clkset() was put in as a function because hubset() was tricky to use when wanting to change the sysclock frequency. Clkset() should also handle updating of debug system too.
xinfreq is for an external oscillator
xtlfreq is for a crystal
both should match the real frequency
clkfreq is where you can fiddle the pll, but it is limited to the PLL / * /
clkset doesn't compile in flexprop
you must have a very old flexprop for clkset() not to work.
Regarding freq constants, to be more correct they are named _xltfreq, _xinfreq and _clkfreq. None are defined at compile time unless you define them. So none match any frequency by default. clkfreq is a system variable so always exists. And finally also clkfreq_ constant, I think it always exists.
flexprop v5.9.2, taqoz v2.8 210401-1230, P2 is revC LMV2019
errfreq defaults to 1_000_000
Compilation fails if _clkfreq ± _errfreq is unachievable. *
so it left me with the pll=175mhz and rcfast
yeah...nooo
Next possible problem our system uses CPUHZ=_clkfreq based on _clkfreq=200_000_000
which isn't necessarily the real system clock output, only requested frequency
even with
waitx ##25_000_000/100 'wait 10ms
hubset ##clkmode_ | %11 'switch to crystal/PLL
result is
TAQOZ# rdmode .bin --- %00000001000000000000010111111000 ok
still in rcfast mode, can change _clkfreq by 10 or 20_000_000 and the pll / * / mode stays the same
Comments
Spin2 code not working for me
changed to different cro, 100 MHz sample, now get a better picture with more samples per cycle, either way, found a problem ?
from a crystal 25 MHz / 32 = 781250 HZ, , no PLL, solid, even output waveform
now 800000 HZ,
cro shows wrong frequency, first half cycle is short
Those two traces look pretty similar to me. Visually, both about 800 kHz and 50% duty. Wrong screenshot maybe?
Something went off-track with the waveforms generation.
Both screenshots say 1uS/DIV, both waveforms periods are about 6.4 uS-long, but, 781,250 Hz would lead to a period of 12.8 uS, and 800,000 Hz would hit 12.5 uS, thus, none seems to be showing the right timings.
@bigtreeman, please, would you mind posting the code used to generate them?
Grrr, yes... I see. It outputs a short burst of pulses and then shuts down. When the main function exits the cog is stopped. I thought this wouldn't matter as the smart pins normally run independent of cogs. But if cog0 stops it seems that the whole system shuts down. So the correct code should be
The endless repeat keeps the cog alive. Sorry, I haven't tested it stand-alone. Instead I've extracted that piece of code from a larger program.
$20000000 is the value for the smart pin Y register which sets the frequency. Y is added to a 32 bit accumulator each clock. Bit 31 of the accumulator becomes the output signal. So $20000000 means one cycle every 8 clocks and 22.5MHz = 180MHz / 8. $200000 would mean one cycle every 2048 clocks or 180MHz / 2048 = 87.9kHz.
Tripped on that myself before. It's because that cog drops all DIRs when it shuts down. The smartpin still needs its DIR high to cycle.
It's been quiet here for a while. Can I summarize what results we got so far...
If nobody reports any positive or negative results I'll test some ~10 boards to check if the oscillator runs well. If I don't find any problems I see the matter as settled if nobody can show a clear procedure of how to reproduce a problem.
Thanks evanh, schematics work for me, I've been doing a bit of reading source and documentation.
spin2 is ok, some of my snippets are working, Taqoz works better, been using forth since the 80's.
Working between propeller 2 instructions and taqoz pretty well answers most questions now.
Using the xtal and pll now gives a fairly steady clock.
backed up the rom taqoz and fudged FLASHBOOT.FTH, so now booting flash 115200, rcfast,
hand crafted assembler shoved into flash boot, not classy but quick and effective.
Can you please post the code you used to switch to PLL and a different system clock (other than 25_000_000)?
**Update: This is for Taqoz V2.7. Taqoz V2.8 see: **
https://forums.parallax.com/discussion/173767/p2-taqoz-v2-8-for-25mhz-crystal-of-kiss-with-sd-card-921600-baud/p1?new=1
Hi, perhaps this helps?
To get Taqoz from SD card running with Kiss+SD, I did:
Removed pulldown R4.
Got Taqoz.zip from https://forums.parallax.com/discussion/167868/taqoz-tachyon-forth-for-the-p2-boot-rom/p1, copied it onto a SD card.
Due to the 25MHz cristal, the baud rate is 1152000 ( = 921600 *25/20 ) .
PuTTY can switch a prop plug to this unusual baudrate. Now you can contact Taqoz on P2. :-)
CLKHZ is not a constant, but this word reads a long at 20 (decimal).
(Therefore "250,000,000 ‘ CLKHZ :=!" does not work here.)
There is in the source:
XIDIV = 1 ' crystal/osc input divider'
VCODIV = 1
CLKMUL = CPUHZ/(XIN/XIDIV)
CLKCFG = 1<<24+(XIDIV-1)<<18+(CLKMUL-1)<<8+((VCODIV-2)&$0F)<<4+PF15
Original value of CLKCFG is : $0100_09F8
This constant is located at 24decimal.
To get a system running at 200 MHz with crystal 25MHz:
$0100_07F8 24 !
200.000.000 20 !
25.000.000 16 !
BACKUP BIX
After booting the baud rate is 921600 as intended.
The modified bootfile is included.
@ManAtWork
Perhaps it would be good to include these steps into your Kiss manual?
The way VCODIV is used, it will only calculate the mode value correctly for VCODIV values 1 and 2. Note there is a general rule of VCO frequency itself must stay >= 100 MHz for good stability. Therefore that 200 MHz sysclock should be very stable.
Of note is the CLKCFG is missing the PLL clock select bits (%SS=%11). I presume Taqoz must add those bits itself.
Ah, I see that XIN there. I suspect that too is a system variable that can be runtime edited, right? That's something that is missing in both Pnut and the Flex suite.
bit delayed, up at Agnes Water surfing, great week
pll to 100 mhz, baud rate to X4, cro on pin 53, 1 mhz steady
looking at the spin2 code for maintaining the system clock in a safe manner
with initial setting -
CON xinfreq = 25_000_000
_clkfreq = 200_000_000
having system variables -
clkmode The current clock mode, located at LONG[$40]. Initialized with the 'clkmode' value.
clkfreq The current clock frequency, located at LONG[$44]. Initialized with the 'clkfreq_' value.
then setting clock with
CLKSET(new_clkmode, new_clkfreq)
avoiding a potential clock glitch
Agnes Waters in Queensland?
Sailed past there 15 years ago. Nice and isolated. How’s the surf?
Usually not much, the northern limit of surf on the east coast before the reef.
Nothing is isolated on the cost with our real estate market these days, but Agnes is
very civilised, just beautiful. Mostly 2-3 foot, dropped to 1-2 foot.
The natives are friendly and respect old surfers, no dropping in.
I've been using this code and want to change those clocking settings then compile a new Taqoz image.
I have to correlate changes in 5 locations.
when I compile with flexprop I get an error which I don't understand
/home/colin/TAQOZ/taqoz-flash.spin2:235: error: syntax error, unexpected number
235 _BAUD long baud_rate
spin2 documentation talks about 2 system wide variables clkmode and clkfreq and are these also used by PASM ?
could we calculate sane values for xmode _XTALFREQ _XDIV _XMUL _XDIVP based on _xinfreq and _clkfreq ?
It seems we shouldn't rely on the default firmware, but compile from source for different hardware setups,
loading firmware is usually done during manufacture
Pnut/Proptool have the two runtime system variables (clkfreq and clkmode). Everything else is compile time, sadly. Most other build tools also support runtime terminal baud as well. But only Taqoz has XIN (crystal frequency). I'm keen to get that changed so that runtime recalibration using a system specified crystal frequency is officially supported with all build systems.
Spin2 uses $40 clkmode and $44 clkfreq
PASM can reference these locations
Taqoz uses the memory locations $40-$7f for the return stack
shuffling the stacks around could push lutfree to $90
and some other system variables could be shoved into $48-$4f
' Offsets in LUT for stacks and system variables
retstk = $000 ' 64 deep'
clkmode = $040
clkfreq = $044
baud_rate = $046
free $048 > $04f
brastk = $050 ' 3 longs for DO or FOR '
datstk = $060 ' 32 deep'
lpstk = $080 ' 3 longs for DO or FOR '
lutfree = $090
auxstk = $090
was -
' Offsets in LUT for stacks
datstk = $000 ' 32 deep'
lpstk = $020 ' 190705 combines loop and branch stack - always 3 longs for DO or FOR '
brastk = $030
retstk = $040 ' 64 deep'
lutfree = $080
auxstk = $080
' The LUT is essentially free from $80 onwards ' * if you don't use the auxstk ?
The actual hubRAM address doesn't matter as long as you use the named symbols.
starting code with
clkmode and clkfreq both read/write now
'' rdmode ( -- n ) read clkmode rdmode rdlong x,#@clkmode jmp #pushx '' rdfreq ( -- n ) read clkfreq rdfreq rdlong x,#@clkfreq jmp #pushxin sysinit i've replaced
with
hubset ##clkmode_ & !%11 'start crystal/PLL, stay in RCFAST waitx ##20_000_000/100 'wait 10ms hubset ##clkmode_ 'switch to crystal/PLLTAQOZ# rdfreq . --- 180000000 ok
TAQOZ# rdmode .bin --- %00000001000000000000011011111000 ok
seems to be xtal, pll 175 mhz, rcfast mode ?
I can manually rewrite clkmode and rerun hubset ##clkmode_
A tad vague on the question being asked ... When running a compiled program, it has no interaction with Taqoz. It takes over the Propeller chip. Each program has its own build of what is where, there is no OS conventions. Hope this answers your question.
That's why I talk about Pnut and FlexSpin separately instead of Spin2 generally. They each have their own indepedant build environments, not decided by the language.
The convention I'm gunning for is the minimal of just having a set of named, and preferably maintained, run-time symbols. Their location is not as important as them just existing.
And the four symbols of the ROM Taqoz are exactly the ones I want: xinfreq, clkfreq, clkmode, baud(debug).
Okay, maybe I've got a solution for what I want without any extra conventions. It's always been there but I hadn't cottoned on to how it was meant to be used.
For programs that want to use the crystal frequency in run-time calculations, they should always define a top level constant for xinfreq or xtlfreq ...
EDIT: Pnut does need to use that run-time baud symbol for its debug baud instead of having its own. Actually, it's more the debug system not handling a new clkset() than the changing of debug baud. Clkset() was put in as a function because hubset() was tricky to use when wanting to change the sysclock frequency. Clkset() should also handle updating of debug system too.
this is a recompile of taqoz V2.8 using spin2 clock control conventions
taqoz is written in spin2 and PASM
xinfreq is for an external oscillator
xtlfreq is for a crystal
both should match the real frequency
clkfreq is where you can fiddle the pll, but it is limited to the PLL / * /
clkset doesn't compile in flexprop
you must have a very old flexprop for clkset() not to work.
Regarding freq constants, to be more correct they are named
_xltfreq,_xinfreqand_clkfreq. None are defined at compile time unless you define them. So none match any frequency by default.clkfreqis a system variable so always exists. And finally alsoclkfreq_constant, I think it always exists.flexprop v5.9.2, taqoz v2.8 210401-1230, P2 is revC LMV2019
errfreq defaults to 1_000_000
Compilation fails if _clkfreq ± _errfreq is unachievable. *
so it left me with the pll=175mhz and rcfast
yeah...nooo
Next possible problem our system uses CPUHZ=_clkfreq based on _clkfreq=200_000_000
which isn't necessarily the real system clock output, only requested frequency
even with
waitx ##25_000_000/100 'wait 10ms
hubset ##clkmode_ | %11 'switch to crystal/PLL
result is
TAQOZ# rdmode .bin --- %00000001000000000000010111111000 ok
still in rcfast mode, can change _clkfreq by 10 or 20_000_000 and the pll / * / mode stays the same