Shop OBEX P1 Docs P2 Docs Learn Events
Prop_Clk — Parallax Forums

Prop_Clk

SeairthSeairth Posts: 2,474
in Propeller 2
The only examples of Prop_Clk that I've seen are called with "FF" for maximum(?) clock speed. But I'm having difficulty seeing how it maps to the HUBSET instruction. Does anyone have more thorough documentation, or the boot ROM snippet related to that command?
«1

Comments

  • evanhevanh Posts: 15,192
    edited 2020-05-31 13:24
    Be warned, issuing that command twice is a potential crash. It was written before the flawed clock select circuit was discovered.

    EDIT: Err, well, you can apply the workaround rules to the mode numbers now I think about it. Which means a two step process to change to the desired mode.

  • evanhevanh Posts: 15,192
    edited 2020-05-31 13:48
    Okay, the FF would have been for the FPGA images. That's how old the example is. Just replace the FF with a 25 bit hex mode number as per HUBSET details.

    The clock select flaw workaround would be to precede the desired mode with this fixed mode: 
    > Prop_Clk 0 0 0 0 F0

    That ensures a clean transition back to RCFAST mode each time before attempting a new mode.

  • SeairthSeairth Posts: 2,474
    edited 2020-05-31 16:02
    That all makes sense. I'll update the documentation to reflect this.

    Update: Actually, I think I still need more details. I've updated Google Docs Prop_Clk to distinguish between the chip and the FPGA, but I don't think it's quite right. I'm guessing that the hex bytes are passed the same order as per Prop_Hex (little endian). However, that begs the question: how does the loader know when the command is complete? If updated using only "F0" above as suggested, how does it know that the remaining three bytes aren't going to be transmitted?
  • evanhevanh Posts: 15,192
    edited 2020-05-31 16:29
    It's a command prompt so ENTER is the terminator. I suspect it'll be a single 32-bit entry, most significant first ...
  • evanhevanh Posts: 15,192
    edited 2020-05-31 17:24
    Yep, here's the ROM source for collecting the hex digits of one number: 
    		mov	y,x			'got first hex digit

.digit		call	#.get			'get any additional hex digits
	if_c	rolnib	y,x,#0
	if_c	jmp	#.digit

		mov	x,y			'done, set result

    And the "Prop_Clk" handling: 
    '
'
' Command - clock setup
'
command_clk	call	#match_device		'receive and check INA/INB filter values

		call	#get_hex		'get clock setting
	if_nc	jmp	#get_command		'if not hex, error, wait for another command

		mov	text_sta,#"."		'transmit acknowledgement character
		call	#transmit_sta

		zerox	x,#24			'clear non-clock bits

		mov	y,x			'switch to partial setting, but in RC fast mode
		andn	y,#%11
		hubset	y

		waitx	##rc_max/200		'wait 5ms

		hubset	x			'switch to full setting

		jmp	#reset_serial		'restart serial at new setting, get next command

    EDIT: Included the MOV x,y in the first snippet for clarity.
  • evanhevanh Posts: 15,192
    So that rule applies to the 32-bit mask numbers as well, ie: Up to 8 consecutive hex digits (most significant first) then a separator, for each mask.
  • evanhevanh Posts: 15,192
    Oh, I guess there is a technicality in that the first digit is not a fix significance. It depends on the number of digits as what the absolute significance of each digit actually is. Regular human ordered format really.
  • SeairthSeairth Posts: 2,474
    What code is that? I see the "fix", but I thought that wasn't in the ROM.

    That aside, assuming the rest matches the ROM, I understand how it works now.
  • cgraceycgracey Posts: 14,133
    The ROM code handles Prop_Clk properly. My only concern about it is that it waits just 5ms before transitioning. So, it might be good to do two Prop_Clk commands, where you initially start up the crystal oscillator and then switch over to the crystal in the second command. That would give 10ms for crystal start-up.
  • SeairthSeairth Posts: 2,474
    cgracey wrote: »
    The ROM code handles Prop_Clk properly. My only concern about it is that it waits just 5ms before transitioning. So, it might be good to do two Prop_Clk commands, where you initially start up the crystal oscillator and then switch over to the crystal in the second command. That would give 10ms for crystal start-up.

    Ok. That happens to be what I updated the example to in the docs. Based on the code above, it means that Prop_Clk always switches back to the 20MHz clock temporarily before switching to the desired clock configuration. I'll make a note of it.
  • evanhevanh Posts: 15,192
    Chip's forgotten the hairiness of the flaw. The ROM code does not shield the user from it. Transitioning from %PPPP = %1111 to anything else while operating from the PLL has a reasonable chance of a lock up.

    His concern over oscillator settling time may partly be from experience. Most likely that experience has been distorted by brushes with the clock select flaw rather than actual settling times. 5 ms is short though. So what he's proposed is actually another step separate from mine. If both are used then it becomes a three step process to make a setting change.

    First step is get cleanly back to RCFAST with $F0. This actually shuts down the crystal oscillator and PLL. Second step is spin up the crystal and PLL without using it. This provides the long settle time that Chip wants. Third step is reissue the same clock settings but just enable the use of it with the least two bit.
  • evanhevanh Posts: 15,192
    So, unless you are certain the prop2 is in RCFAST already, I'd do it this way: 
    Sender:    "> Prop_Clk 0 0 0 0 F0"+CR
Prop2:    "."

(Sender waits ~20ms.)

Sender:    "> Prop_Clk 0 0 0 0 19D28F8"+CR
Prop2:    "."

(Sender waits ~20ms.)

Sender:    "> Prop_Clk 0 0 0 0 19D28FB"+CR
Prop2:    "."
  • Dave HeinDave Hein Posts: 6,347
    edited 2020-06-01 01:17
    I'm just curious, but how does the Prop boot code adjust it's serial bit time for the new clock rate? Don't you have to send it some special characters each time the clock frequency changes?
  • evanhevanh Posts: 15,192
    It's the <GREATERTHAN> and <SPACE>. I think there is two phases internal to the program timing in the prop2. Initial course auto-baud is done after reset_serial. Then fine calibration is repeated on every successive "> ".
  • Cluso99Cluso99 Posts: 18,069
    edited 2020-06-01 03:21
    Dave,
    The boot code is published - "ROM_Booter_v33_01j.spin2". I can post the source and/or the listing if you can't find it.

    IIRC it only autobauds the once when it is in serial mode and sees the "> " characters. I'm not sure what the Prop_Clk command does, but presume it changes the baud setting in the smartpins too.
    However, if from the serial boot prompt you enter Ctl-D or Esc to enter the debug/monitor or TAQOZ in ROM, we take the setting from the serial that is already loaded into the smartpins.
  • cgraceycgracey Posts: 14,133
    If you are talking to the booter over serial, the chip is in RCFAST mode. Any change from RCFAST could only have come from a Prop_Clk command since reset. You would know, because only you could make that command.
  • evanhevanh Posts: 15,192
    edited 2020-06-01 03:46
    Chip,
    The coder needs to know that if he is doing more than one change, for whatever reason, that this flaw is present ... and there a suitable way to handle it.

    Maybe note that once the PLL is selected, any future changes there on, from any software, until a chip reset, needs to handle this issue.

    PS: Secondary boot loaders and high-level languages are built with a workaround, but pure pasm2 by nature is not and neither is the ROM.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    The coder needs to know that if he is doing more than one change, for whatever reason, that this flaw is present ... and there a suitable way to handle it.

    Maybe note that once the PLL is selected, any future changes there on, from any software, until a chip reset, needs to handle this issue.

    PS: Secondary boot loaders and high-level languages are built with a workaround, but pure pasm2 by nature is not and neither is the ROM.

    Yes, I see what you are saying.

    Whatever the new Prop_Clk frequency is, it can auto-baud to 1/10th the new clock frequency on a subsequent "> " pattern.

    It might be good policy to always do a Prop_Clk at the end to return to RCFAST, so that the downloaded code doesn't have to know anything special about the current clock mode.
  • evanhevanh Posts: 15,192
    edited 2020-06-01 04:38
    cgracey wrote: »
    It might be good policy to always do a Prop_Clk at the end to return to RCFAST, so that the downloaded code doesn't have to know anything special about the current clock mode.
    Eric decided that too. Loadp2 defaults back to RCFAST after downloading unless instructed otherwise ...

    EDIT: Ah, he's changed it since I last looked. Now uses the prior mode to switch back to RCFAST first. Note the final 100 ms pause to ensure the crystal oscillator fully powers down before moving on. 
    		...

		' switch back to rcfast mode, maybe
		' if the binary was patched with -PATCH then we skip this
		test	flagbits, #FLAGBIT_PATCHED wz
	if_nz	jmp	#start_cog		 ' patched, so start right now
		' go back to rcfast mode
		andn	 clkmode_, #3
		hubset	 clkmode_
		hubset	 #0
start_cog
		waitx	 ##25_000_000/10
		coginit	#0,startaddr		'launch cog 0 from starting address
  • SeairthSeairth Posts: 2,474
    cgracey wrote: »
    evanh wrote: »
    Chip,
    The coder needs to know that if he is doing more than one change, for whatever reason, that this flaw is present ... and there a suitable way to handle it.

    Maybe note that once the PLL is selected, any future changes there on, from any software, until a chip reset, needs to handle this issue.

    PS: Secondary boot loaders and high-level languages are built with a workaround, but pure pasm2 by nature is not and neither is the ROM.

    Yes, I see what you are saying.

    Whatever the new Prop_Clk frequency is, it can auto-baud to 1/10th the new clock frequency on a subsequent "> " pattern.

    It might be good policy to always do a Prop_Clk at the end to return to RCFAST, so that the downloaded code doesn't have to know anything special about the current clock mode.

    That wouldn't work, would it? As soon as the load completes, the code starts executing. There's no opportunity to send additional commands.
  • cgraceycgracey Posts: 14,133
    Seairth wrote: »
    cgracey wrote: »
    evanh wrote: »
    Chip,
    The coder needs to know that if he is doing more than one change, for whatever reason, that this flaw is present ... and there a suitable way to handle it.

    Maybe note that once the PLL is selected, any future changes there on, from any software, until a chip reset, needs to handle this issue.

    PS: Secondary boot loaders and high-level languages are built with a workaround, but pure pasm2 by nature is not and neither is the ROM.

    Yes, I see what you are saying.

    Whatever the new Prop_Clk frequency is, it can auto-baud to 1/10th the new clock frequency on a subsequent "> " pattern.

    It might be good policy to always do a Prop_Clk at the end to return to RCFAST, so that the downloaded code doesn't have to know anything special about the current clock mode.

    That wouldn't work, would it? As soon as the load completes, the code starts executing. There's no opportunity to send additional commands.

    Oh, you're right. So, the downloaded code would have to know if it was starting under a PLL clock mode with divide=1, if it intended to change it.
  • evanhevanh Posts: 15,192
    True. Or the loaded program could blindly use $F0 to cleanly switch back to RCFAST before attempting what it wants.
  • SeairthSeairth Posts: 2,474
    I have updated the Prop_Clk section, mostly to point to the main configuration section (Configuring the Clock Generator) for these details. What's currently in there doesn't quite match what's being said here, though.

    Is it always safe to issue a HUBSET #0 (or HUBSET #$F0)? Or do you need to switch back to the internal clock without disturbing the other settings?
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    True. Or the loaded program could blindly use $F0 to cleanly switch back to RCFAST before attempting what it wants.

    Does #$F0 always work? I didn't know about this.
  • evanhevanh Posts: 15,192
    edited 2020-06-02 06:29
    cgracey wrote: »
    evanh wrote: »
    True. Or the loaded program could blindly use $F0 to cleanly switch back to RCFAST before attempting what it wants.
    Does #$F0 always work? I didn't know about this.
    Yep, always seemed to work - https://forums.parallax.com/discussion/comment/1466461/#Comment_1466461
    It wasn't accepted as a good idea originally - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494

    Some months later it was put forward again - forgotten where and who. I now use it for short code examples that need to set the clock frequency.

  • potatoheadpotatohead Posts: 10,254
    Pretty sure that was Rayman.
  • SeairthSeairth Posts: 2,474
    evanh wrote: »
    cgracey wrote: »
    evanh wrote: »
    True. Or the loaded program could blindly use $F0 to cleanly switch back to RCFAST before attempting what it wants.
    Does #$F0 always work? I didn't know about this.
    Yep, always seemed to work - https://forums.parallax.com/discussion/comment/1466461/#Comment_1466461
    It wasn't accepted as a good idea originally - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494

    Some months later it was put forward again - forgotten where and who. I now use it for short code examples that need to set the clock frequency.

    Okay. Just to be clear, please review the Configuring the Clock Generator section, particularly the WARNING paragraph and the example below it.
  • evanhevanh Posts: 15,192
    That's all good Seairth. Now I have to let you down by saying that's the unsanctioned simple approach.

    The official line is use one of two controlled handover methods. Either by always reverting to RCFAST first, called RCFAST handover, or by passing a copy of the currently set mode to the loaded program, called Mailbox handover, at hubRAM address $18. Further reading - https://forums.parallax.com/discussion/comment/1466702/#Comment_1466702

  • evanhevanh Posts: 15,192
    Which also applies to a program's internal mode adjustments. A program changing itself back to RCFAST, it should be doing it as Eric has above by using the existing copy of the last mode set. 
    		andn	 clkmode_, #3
		hubset	 clkmode_
		hubset	 #0
  • evanhevanh Posts: 15,192
    edited 2020-06-03 04:37
    Oh, that HUBSET #0 isn't technically needed for an internal mode change. Just using the copy of the old mode is enough. Then proceed with the new mode. Still just three HUBSET instructions, eg: 
            ANDN    clkmode, #3
        HUBSET  clkmode               'set 20MHz+ mode
        MOV     clkmode, ##%1_100111_0100101000_1111_10_00    'New mode for sysclock frequency
        HUBSET  clkmode               'enable crystal+PLL, stay in 20MHz+ mode
        WAITX   ##25_000_000/100      'wait ~10ms for crystal+PLL to stabilize
        AND     clkmode, #3
        HUBSET  clkmode               'now switch to PLL running at 148.5MHz
Sign In or Register to comment.