Shop Learn
TAQOZ sysclock confusion — Parallax Forums

TAQOZ sysclock confusion

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?

«1

Comments

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-24 11:41

    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.

  • YanomaniYanomani Posts: 1,306

    @ManAtWork said:
    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. :(

    Up to the extent of my own NOOByness, a sound Yes!

    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.

    Perfect! :smiley:

  • YanomaniYanomani Posts: 1,306

    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.

    $11008F8 HUBSET
    $11008FB HUBSET
    180000000 ' CLKHZ ==!
    

    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.
    :s

  • 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.

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 00:01

    @ManAtWork said:
    Im still too stupid.

    You, stupid??? What about me? :frowning:

    Please, just a bit of patience. There are at least some problems, as I stated before:

    @Yanomani said:
    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.

    So, one needs to mimics the same procedure in TAQOZ, as it's done in PASM2

    HUBSET #$F0 'set ~20 MHz+ (RCFAST) mode
    HUBSET ##%1_100111_0100101000_1111_10_00 'enable crystal+PLL, stay in RCFAST mode
    WAITX ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
    HUBSET ##%1_100111_0100101000_1111_10_11 'now switch to PLL running at 148.5 MHz
    In 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) mode
    HUBSET #$C8F8 'enable crystal+PLL, stay in RCFAST mode
    WAITX ##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 MHz

    P.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...

  • Cluso99Cluso99 Posts: 17,955

    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.

  • bigtreemanbigtreeman Posts: 31
    edited 2021-08-25 01:21

    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

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 02:34

    @bigtreeman said:
    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 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)
    staying in Xl mode %SS=10 is great
    sysclk is now xtal, pin 31 is now locked to 1mhz
    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

    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).

  • bigtreemanbigtreeman Posts: 31
    edited 2021-08-25 04:00

    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.

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 04:13

    @bigtreeman said:
    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..

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 04:15

    @bigtreeman said:

    >

    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

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 05:28

    @bigtreeman said:
    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:

    CLKHZ . 20000000
    25000000 ' CLKHZ 2+ !
    CLKHZ . 25000000
    $0 HUBSET
    $8 HUBSET
    $A HUBSET
    53 PIN 1 MHZ

    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:

    $4 HUBSET
    $6 HUBSET

    and

    $C HUBSET
    $E HUBSET

    are valid combinations (tweaking no-caps/15 +15 pF/30 + 30 pF), in place of the two non-zero HUBSET comands.

  • bigtreemanbigtreeman Posts: 31
    edited 2021-08-25 07:53

    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)

    CON
      _xtlfreq = 25_000_000
      _clkfreq = 180_000_000
    
    PUB go()
      pinstart (53, P_NCO_FREQ + P_OE, 1, $20000000)
    

    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.

  • Cluso99Cluso99 Posts: 17,955

    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.

  • evanhevanh Posts: 11,673
    edited 2021-08-25 11:18

    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.

  • evanhevanh Posts: 11,673

    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.

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 13:33

    @bigtreeman said:
    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

    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))

    04 hubset
    1mhz=990khz
    06 hubset
    1mhz=1.001mhz

    (~15 pF per pin, so load of ~7.5 pF)

    08 hubset
    1mhz=985.2khz
    0a hubset <-- IMHO, Needs to be $0A
    1mhz=999.6 khz

    I'm just not seeing any try with $0C and $0E:

    (~30 pF per pin, so load of ~15 pF)

    $0C hubset
    1mhz=??????????
    $0E hubset
    1mhz=??????????

  • YanomaniYanomani Posts: 1,306

    @bigtreeman said:

    can I read the clock register ?

    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.

  • YanomaniYanomani Posts: 1,306
    edited 2021-08-25 14:14

    @Yanomani said:

    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... (bad bubble memory sectors, floating on my mind...)

    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.

  • evanhevanh Posts: 11,673
    edited 2021-08-25 14:23

    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

  • YanomaniYanomani Posts: 1,306

    @evanh said:
    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! :smiley:

    We need the PLL/VCO-thread spin-off, more than ever...

  • bigtreemanbigtreeman Posts: 31
    edited 2021-08-26 00:08

    @ManAtWork said:
    Anyway... Bigtreeman, could you please run the following Spin2 code with PropTool or PNut? (replace 53 with any pin number you like)

    CON
      _xtlfreq = 25_000_000
      _clkfreq = 180_000_000
    
    PUB go()
      pinstart (53, P_NCO_FREQ + P_OE, 1, $20000000)
    

    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.

    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

  • evanhevanh Posts: 11,673

    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.

Sign In or Register to comment.