TAQOZ sysclock confusion
ManAtWork
Posts: 2,176
in Propeller 2
Colin (bigtreeman) reported a possible problem with the KISS board. He says he can't get a stable system clock and as consequence serial communication and PWM/NCO outputs have problems due to clock jitter.
I don't think it is a hardware problem because when I setup the clock in Spin2 everything is working as expected.
CON _xtlfreq = 25_000_000 _clkfreq = 180_000_000 PUB go() pinstart (32, P_NCO_FREQ + P_OE, 1, $20000000)
outputs exactly 22.50MHz. However if I type the following in TAQOZ
25000000 CLKHZ 32 PIN $40000000 NCO
I only get 6.17 instead of 6.25MHz. The KISS board I'm using has a 25MHz instead of the standard 20MHz crystal. I think it's only a configuration or documentation misinterpretation problem. The official TAQOZ doc doesn't tell much about the CLKHZ command. What is the correct way to tell TAQOZ that there is a 25MHz crystal connected?
Comments
Hi @ManAtWork
IIRC, CLKHZ is a constant, so the right way to change its value is:
25,000,000 ‘ CLKHZ ==!
And it can be checked by typing just CLKHZ alone, at the command prompt.
Hope it helps
Henrique
Warning: I am as a MOE in TAQOZ, as in any "flavour" of C, so take the above advice with LOTS of salt!!!
P.S. In case TAQOZ is still running based on RCFAST (not yet switched to the external crystal oscillator, and need recalculations), you can adjust the CLKHZ constant to match the real frequency of RCFAST, as measured by your tests.
So (6.25 / 6.17) * 25000000 ~= 25324149
The new adjustment would be:
25,324,149 ‘ CLKHZ ==!
and using CLKHZ alone, at the command prompt, will confirm its effectiveness.
N.B. RCFAST ~= 25000000 on P2 silicon RevB and RevC chips only, but I'm almost sure that's the case
Ok, thanks, so that confims what I've already suspected. Assigning CLKHZ does not have any influence on the actual clock/PLL setting but just sets the constant for other calculations like baud rate. So I think the correct procedure would be to use HUBSET to configure the PLL correctly. Or is there a simpler way? Unfortunatelly, I'm also a total NOOB when it comes to TAQOZ.
But at least I don't have to worry that there is a problem in the hardware. The crystal oscillator runs pretty stable and works as expected in Spin or C. And TAQOZ seems not to use the crystal at all unless it is told to do so.
Up to the extent of my own NOOByness, a sound Yes!
Perfect!
It's worth of note that any use of HUBSET under TAQOZ is supposed to follow the same timelly sequences, as if it was done in PASM2, so, it's important to EVER follow the correct procedure, when changing sysclk.
When comparing to the same SPIN2 procedure, one should remember that the involved WAITS are someway "undercovered" by the language syntax.
Im still too stupid.
should set the PLL to 180MHz with XI=25MHz (M=36 D=5). Of course, the second HUBSET causes the clock frequency to change and I can't see anything in the terminal any longer. How do I combine two commands in a single line? Simply writing them one after the other doesn't work.
Maybe moving this thread to ForthSpace would help a bit with gaining attention of more Forth oriented devs ?
Just a thought.
I'm away from my KISS board now but I'll try to figure it out when I'm back home. Are you using TAQOZ in ROM or the Reloaded (much richer in featres) version ?
I've found out that setting CLKHZ has no immediate impact on the baud rate. So at least one more command is required to update it.
You, stupid??? What about me?
Please, just a bit of patience. There are at least some problems, as I stated before:
So, one needs to mimics the same procedure in TAQOZ, as it's done in PASM2
HUBSET #$F0 'set ~20 MHz+ (RCFAST) modeHUBSET ##%1_100111_0100101000_1111_10_00 'enable crystal+PLL, stay in RCFAST modeWAITX ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilizeHUBSET ##%1_100111_0100101000_1111_10_11 'now switch to PLL running at 148.5 MHzIn the above case, 148.5 MHz would be the resulting frequency, if XI is receiving 20.0000 MHz.
For your board, where 25.0000MHz is feeding XI, must rework the values, towards the intended Sysclk.
Then it becomes (for 180 MHz, as you've yet calculated):
HUBSET #$C8F0 'ensure/set ~25 MHz+ (RCFAST) modeHUBSET #$C8F8 'enable crystal+PLL, stay in RCFAST modeWAITX ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
´´´WAITX ##25_000_000/100 'wait ~10ms for crystal+PLL to stabilize´´´
HUBSET #$C8FB 'now switch to PLL running at 180 MHzP.S. Also note that the above ##25_000_000/100 wait (in mS) is related to the internal RCFAST oscillator, not the external crystal that's in your board.
There is another procedure that needs to be executed, before regainning control of the terminal, due to the needed BAUD rate recalculation, or you'll lose control over the serial link.
I'm just trying to find it, it's a single command...
Please remember TAQOZ in ROM was written before the clock changing problems were discovered. However, having said this, when TAQOZ boots the first time after a power up the clock problem does not exist as it is switching from RC to xtal. TAQOZ will initially use the RC mode and the baud is likely copied from the autobaud sequence detected by the serial boot ROM. I know we asked Chip to pass the autobaud info when calling TAQOZ/Monitor/SD code but then IIRC we just used the preset baud setting.
I will try to remember to ask Peter when I chat to him today.
So looking in P2X8C4M64P datasheet-20210709
page 18 system clock settings
programmable xtal loading 15 pF for high freq
did I also read a possible range of 7.5 > 15 pF
is there a preferred CL for the crystal, the range might suggest a median of 8-10 pF
Yanomani
I'm going through the hubset set clock mode
previous to HUBSET settings
31 PIN 1 MHZ
monitor with a cro
going to PLL mode %SS=11 kills clock (and board)
going to Xl mode %SS=10 is great
$C8FA HUBSET
sysclk is now xtal, pin 31 is now locked to 999.6 khz
but still seeing some ugly shifts in the pin 31 signal
Is there a way I can modify rom TOQAZ to use xtal at boot
also TOQAZ for SD card
Hi @bigtreeman
First we need to understand what board we're talking about, so please, let me know.
P.S. 2 - Going back to the first post, I've noticed ManAtWork told us that YOU has a KISS board (shame on me, for my blindness).
P.S. also, using pin 31 (pad 49) as a witness-output can, eventually, mess a bit with the XI/XO stability (sure, it depends on wich pcb we are talking about), so it's wiser to direct your output signal to another pin-group, different from the ones connected to V2831 (pad 47).
no prob, now using pin 53, pad 84,
same result
I've got a 25 Mhz oscillator and different xtals on back order,
see what happens with a solid clock source.
You can try to tweak the internal loading capacitors control bits, in order to verify it there is a better setup (including no caps, at all).
Refering to pages #55 and #56 of v35 - Rev B_C silicon documentation:
It's important to note that at least 5 mS should separate the HUBSET command that selects the value of the loading caps and enables XI/XO circuit (%CC bits), from the next HUBSET, wich effectivelly routes the XI input, as to become the clock reference for the P2 (%SS bits).
When in terminal mode, it's almost impossible to type/execute both comands faster than this (perhaps "The Flash" could do it...), unless they can be streamlined, at the same command line.
Another important thing to do, is being ensured that CLKHZ is reporting 25,000,000, before the change of clock source is made (see above, post #2); if not, adjust it, and check again..
>
Would you mind posting the exact command sequence that lead to the above resulting waveform?
53 PIN 1 MHZ
$C8F0 HUBSET
$C8F8 HUBSET
$C8FA HUBSET
CLKHZ . 20000000
25000000 ' CLKHZ 2+ !
CLKHZ . 25000000
1 MHZ
I'll change clkhz first,
hmmm, still twitching like an epileptic
Please, try typing the following command sequence:
The "$0 HUBSET" can be ommited, but it's there just to remember the fact that ALL bits are set to ZERO, during RESET.
P.S. Also:
and
are valid combinations (tweaking no-caps/15 +15 pF/30 + 30 pF), in place of the two non-zero HUBSET comands.
reset
53 pin 1 mhz
clkhz . 20000000
1mhz=1.228/9mhz
25000000 ' clkhz 2+ !
1 mhz
1mhz=982.8khz
$09 hubset drops the 1mhz clock to 1.200 khz
and blows the serial baud rate
reset ...
04 hubset
1mhz=990khz
06 hubset
1mhz=1.001mhz
07 hubset
dead duck
pll clksource with pll turned off was never going to work
08 hubset
1mhz=985.2khz
0a hubset
1mhz=999.6 khz
0b hubset
1mhz=noclk, dead duck
reset ..
same noise from RCFAST
can I read the clock register ?
where is the clock schematic, easier to see what is happening
Am I seeing the loading caps interfering with RCFAST, should be held OFF when xtal not used?
is it ok to select wrong configurations,
I'll get my other cro working to double check
I still don't understand what you are doing in TAQOZ but if I interpret the posts cotrrectly the diagram shows a glitch while the PC is still in RCFAST mode. That is very strange. I'd understand that the PLL can be disturbed by noise on the XI pin. But RCFAST should be stable (except for long term thermal drift) under all conditions. If there's a brown out or something wrong with the supply the P2 should crash long before any clock or counter malfunction occurs.
I'm pretty sure this doesn't have to do anything with the crystal loading caps. Mismatched loading caps can cause the frequency to drift some 100ppm or cause a longer start-up time of the oscillator (or no start up at all for extreme cases). But it doesn't cause the frequency to go way off.
If the slope of the sine wave at XI is too shallow the transformation to a square wave (schmitt trigger or something) for the internal clock can be confused. This would insert extra pulses and cause the PLL to de-syncronize, trying to lock to a seemingly higher frequency. Chip explained this in a thread I don't remeber at the moment. This is the reason why the XO and XI traces should be kept as short as possible. In the first version of the KISS board I haven't followed this because it was designed earlier. There where two test points connected to XI and XO. The traces are only a few mm long so this shouldn't be too harmful it you don't switch too many neighbouring pins at the same time.
I have fixed this in the new layout (with SD card).
Anyway... Bigtreeman, could you please run the following Spin2 code with PropTool or PNut? (replace 53 with any pin number you like)
If it outputs a stable 22.5MHz then we can be sure that there is no hardware problem and all the above confusion is caused by wrong use of TAQOZ. We can sort that out later hopefully with the help of some TAQOZ expert. But first, I want to know if there's a problem with the hardware or not.
I spoke to Peter today. He is working out a set of commands. I’ll post the commands when I get them.
I agree with @ManAtWork that first you need to prove the hardware with something common we all understand.
I've been interested in similar details of late. It occurs to me that Taqoz is probably the only system that has a runtime changeable system variable for handling different crystals. After all, Peter targetted two frequencies, 12 and 20 MHz, from the outset.
Another issue is setting the terminal/debug comport baud. There needs to be a provided routine for this so that it can be updated after a sysclock frequency change. And also need a symbol or system variable of what said baud was originally set to. Either that or clkset() updates it automatically. Again, I think this is already there under the hood with Taqoz. Not so with Pnut/PropTool.
There is normally no need to change the sysclock during run time. I only had one single case where this was required. It was a geocache gadget with the P1 powered from a CR2032 battery. I had to switch between RCSLOW and XOSC to save power. But even there there was no need to adjust the baud rate or any timer/divider because when running RCSLOW the P1 did nothing but waiting for wakeup.
TAQOZ needs on-the-fly clock adjustment because it needs constant terminal input/output before and after PLL configuration.
My experimental testing is evolving, I've mostly moved to C and even starting to use Spin in recent day. In pure assembly I just did whatever was needed, so I had my own debug code and reconfiguration was part of that.
Rather than going my own way again, I'm looking have this as a supported general feature of the HHLs. Maybe even using those agreed on mailboxes.
Thanks for trying all the above combinations.
I believe the ones dealing with HEX representations of the involved four bits need to be preceeded by "$", since I really don't know how TAQOZ will interpret them the way they are expressed.
In case of enabling the PLL (07, or $07) in that context, without all the pre-conditionning steps, it'll never work: a bricked-till-reset P2 is all you can get, acting that way, thus another common sense. The same fate will hit when trying $03, $0B and $0F.
Sure, activating RCSLOW (09, or $09) is really expected to drop the 1 MHz output-signal to something in the KHz range, so the outcome is no surprise, at all. The same can be said about using $01, $05, and $0D.
From your test set, it can be noted that the 25.0000 MHz external crystal and the internal inverter/buffer feedback circuit seems to work with at least two-out-of-three possible configurations of loading capacitors, despite the differing resulting frequencies:
(no internal loading caps, only stray capacitances (pads/tracks/vias (if any))
(~15 pF per pin, so load of ~7.5 pF)
I'm just not seeing any try with $0C and $0E:
(~30 pF per pin, so load of ~15 pF)
No, the HUBSET instruction only forwards the appropriate fields to any subsystem under its control; the Clock Generator configuration is just one of them.
Copy(ies) of any setups that can be modifyed by doing a HUBSET should be kept accessible to any other routines that could relly on them.
As a principle, each susbsytem must restrict its own accesses to the appropriate bits, so good shielding methods must be enforced (e.g., the use of locks), mainly when there are any possibilities of interrupts being involved.
Back in 2019, there are some mentions to "CRUISE", "CONBAUD" and "EXTEND", but they seem to focus on P2-ES and P2D2...
https://forums.parallax.com/discussion/comment/1478673/#Comment_1478673
Hope they can be of any help.
Bigtreeman,
Read up on HUBSET in the silicon google doc. All the config/mode details are in there.
As for schematics of what the mode bits do, they do exist - as I recently discovered myself, but they're pretty full-on engineering. https://forums.parallax.com/discussion/comment/1433409/#Comment_1433409
And that PLL sub-block here https://forums.parallax.com/discussion/comment/1393213/#Comment_1393213
Thanks a lot, evanh!
We need the PLL/VCO-thread spin-off, more than ever...
help of some TAQOZ expert. But first, I want to know if there's a problem with the hardware or not.
setup flexprop,
ok got that talking, can also get TAQOZ and monitor
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
I've only used Loadp2 directly (Kubuntu) to access the Prop2 Eval Board so can't comment too much on FlexProp's operations but that should've worked assuming you already have a terminal program doing the same for Taqoz.