P2 Reset - possible problem

12346»

Comments

  • evanhevanh Posts: 6,643
    edited 2019-03-07 - 05:18:07
    Peter,
    Use 15 when PLL selected and 0 when RCFAST selected. Toggle between the two.

    EDIT: I've just tested a %PPPP only change (not switching away from PLL) and it worked for 226 cycles before failing.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Peter JakackiPeter Jakacki Posts: 8,159
    edited 2019-03-07 - 05:25:09
    Ok, I'm not seeing it as frequently for some reason but I ran a loop which continue to print the loop count until I stopped it or it froze, which it did.
    TAQOZ# CRUISE _clk @ .L --- $0100_0EFB ok
    TAQOZ# CRLF 0 BEGIN CR DUP . 3 SPACES 1+   0 HUBSET CRUISE KEY UNTIL --- 
    10155  �
    

    But then I did this another couple of times:
    TAQOZ# CRLF 0 BEGIN CR DUP . 3 SPACES 1+   0 HUBSET CRUISE KEY UNTIL --- 
    1421  � ---  ok
    TAQOZ#  ---  ok
    TAQOZ#  ---  ok
    TAQOZ# CRLF 0 BEGIN CR DUP . 3 SPACES 1+   0 HUBSET CRUISE KEY UNTIL --- 
    1128  �
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2CHIP-1.jpg
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • evanhevanh Posts: 6,643
    edited 2019-03-07 - 05:30:05
    cgracey wrote: »
    If you don't know that value, you cannot safely switch away from a potential PLL mode.
    Some of my programs fill (with data) 100% of hubRAM. :(
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • cgraceycgracey Posts: 10,930
    edited 2019-03-07 - 05:35:26
    So, is anyone convinced we have some intractable problem? Anything that might necessitate a power cycle?
  • Peter JakackiPeter Jakacki Posts: 8,159
    edited 2019-03-07 - 06:09:32
    After some further tests I find that I am seeing the problem when I am running at 180MHz or about half of that, but not when I am running 300Mhz or 120MHz or 40MHz where I press a key to exit the test. I find though that my reset on the eval board brings it back up.

    I created a simple PUMP word that continued to print the loop count until it froze or I hit a key. Whenever it froze I reset the unit again and TAQOZ loaded back up off SD and printed out its splash screen without any problems. Three problems occurred at 180MHz after 55,320 times and at 80MHz after 37,928 times and at 180MHz after 2 times.
    -------------------------------------------------------------------------------
      Parallax P2  *TAQOZ* Extensible Firmware  V2.0 'CHIP' 180MHz 190212-1700
    -------------------------------------------------------------------------------
    TAQOZ#  ---  ok
    TAQOZ# CRUISE .CLK --- 180MHz ok
    TAQOZ# : PUMP CRLF 0 BEGIN 100 us CR DUP . 3 SPACES 100 us 1+ 0 HUBSET _clk @ HUBSET KEY UNTIL 5 ms ; ---  ok
    TAQOZ# PUMP --- 
    55321   
    -------------------------------------------------------------------------------
      Parallax P2  *TAQOZ* Extensible Firmware  V2.0 'CHIP' 180MHz 190212-1700
    -------------------------------------------------------------------------------
    TAQOZ# COAST .CLK --- 120MHz ok
    TAQOZ# PUMP ???  ---  ok
    TAQOZ# : PUMP CRLF 0 BEGIN 100 us CR DUP . 3 SPACES 100 us 1+ 0 HUBSET _clk @ HUBSET KEY UNTIL 5 ms ; ---  ok
    TAQOZ# PUMP --- 
    201367    ok
    TAQOZ# TURBO .CLK --- 300MHz ok
    TAQOZ# PUMP --- 
    206416    ok
    TAQOZ# _clk @ .L --- $0100_0EFB ok
    TAQOZ# 80 P2MHZ _clk @ .L --- $0100_03FB ok
    TAQOZ# PUMP --- 
    37928   
    -------------------------------------------------------------------------------
      Parallax P2  *TAQOZ* Extensible Firmware  V2.0 'CHIP' 180MHz 190212-1700
    -------------------------------------------------------------------------------
    TAQOZ# : PUMP CRLF 0 BEGIN 100 us CR DUP . 3 SPACES 100 us 1+ 0 HUBSET _clk @ HUBSET KEY UNTIL 5 ms ; ---  ok
    TAQOZ# 40 P2MHZ _clk @ .L --- $0100_01FB ok
    TAQOZ# PUMP --- 
    101268    ok
    TAQOZ# CRUISE .CLK SPACE _clk @ .L --- 180MHz $0100_08FB ok
    TAQOZ# PUMP --- 
    2   
    -------------------------------------------------------------------------------
      Parallax P2  *TAQOZ* Extensible Firmware  V2.0 'CHIP' 180MHz 190212-1700
    -------------------------------------------------------------------------------
    TAQOZ# 
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2CHIP-1.jpg
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • I am German so sometimes I need to look up English words, for understanding.

    Lately I stumbled over fortnight, something that happens in about two weeks. It looks like we need to invent a new word, the forthnight.

    That is the amount of time @Peter Jakacki needs to implement a 2 weeks solution in one night...

    Gosh, I really need to get a handle on that TAQOZ thinking.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Okay, that figures. My testing was using a random 10 MHz multiple each cycle.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • jmgjmg Posts: 13,261
    After some further tests I find that I am seeing the problem when I am running at 180MHz or about half of that, but not when I am running 300Mhz or 120MHz or 40MHz where I press a key to exit the test. I find though that my reset on the eval board brings it back up.

    That could be the clock-delays to bit change being longer than 1 sysclk and creating varying width runt clocks ? Some are tolerated, some freeze P2 ?



  • jmgjmg Posts: 13,261
    cgracey wrote: »
    So, is anyone convinced we have some intractable problem? Anything that might necessitate a power cycle?

    I think the PLL exit has a work-around/usage rule to apply.
    There was a download-freeze issue, but that seemed more USB-side and IIRC a handshake at end fixed that ? evanh may confirm that may be another rule to apply ?
    When I created XTAL lockups, a reset pin always recovered, so I've never seen a power-cycle-needed level issue on P2.
  • I never got back to the USB testing. There was other things happening.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • As it happens there is a convention shared by TAQOZ, p2gcc, and fastspin for storing the clock configuration in low HUB memory:
    $14 = current clock frequency
    $18 = current clock mode
    $1c = current default serial baud (not relevant to this case :) )
    
    fastspin stores the clock mode setting with the bottom two bits set to 0 in $18, but I think it's safer to explicitly clear those bits before using them
  • Thanks Eric.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Right here's my new startup code for that:
    		hubset	clk_mode		'switch to RCFAST using known prior mode
    		mov	clk_mode, ##_SETFREQ	'replace old with new
    		hubset	clk_mode		'setup for new mode, still RCFAST
    		waitx	##20_000_000/100	'~10ms
    		mov	pa, clk_mode
    		or	pa, #_XSEL
    		hubset	pa			'engage
    

    "clk_mode" defaults to a value of 0 when the binary is built. But it located at cog address 6 (byte address $18 in the binary file) so that any boot-loader can poke in an updated mode that it might have set.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • One instruction less:
    		hubset	clk_mode		'switch to RCFAST using known prior mode
    		mov	clk_mode, ##_SETFREQ	'replace old with new
    		hubset	clk_mode		'setup for new mode, still RCFAST
    		waitx	##20_000_000/100	'~10ms
    		hubset	##_ENAFREQ		'engage
    
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanh wrote: »
    One instruction less:
    		hubset	clk_mode		'switch to RCFAST using known prior mode
    		mov	clk_mode, ##_SETFREQ	'replace old with new
    		hubset	clk_mode		'setup for new mode, still RCFAST
    		waitx	##20_000_000/100	'~10ms
    		hubset	##_ENAFREQ		'engage
    

    That's right!
  • cgraceycgracey Posts: 10,930
    edited 2019-03-08 - 04:43:32
    Following the rules on only changing the PLL when switched to other sources, I could not get the P2 to crash all day.
  • evanhevanh Posts: 6,643
    edited 2019-03-08 - 13:50:38
    I've discovered I can happily switch over from RCFAST to PLL on the very next instruction after setup. Same as going from PLL to RCFAST. The WAITX isn't needed for stability, just timing accuracy.

    Can't combine it down to a single HUBSET though, presumably because of the aforementioned glitching with %PPPP == %1111. I'm using this value in all cases.

    I'm not getting the max current spikes on the power supply either. I've been watching it on the scope for a while. No sign of any issues, all nice and regular timing. Here's scope screenshot showing the steps from the random clock frequencies and a zoom of most of one cycle:
    Orange is 5 Volt PC-USB on the cable side of F401, 5 volts at 2 div below top.
    Blue is 5 Volt Common at accessory header, 5 volts at 2 div below top.
    Green is bench-top current supply to 5 Volt Common, 250 mA/div, 0 mA at 2 div above bottom.
    Pink is pin#62 comport reporting.
    pin_lat0138.PNG
    pin_lat0139.PNG
    640 x 480 - 14K
    640 x 480 - 12K
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanhevanh Posts: 6,643
    edited 2019-03-08 - 14:07:29
    And here's one that is left running without reloading:
    pin_lat0140.PNG

    And the source for the test loop
    '--------------------------------------------
    'MUL on all cogs
    '
    		loc	ptra, #\@multest
    		mov	count, #15
    .mult
    '		waitx	#500
    		coginit	count, ptra
    		djnz	count, #.mult		'fall through on zero
    '
    'reconfig diag port for RCFAST
    '
    .txempty
    		rqpin   inb, #tx_pin	wc	'transmiting? (C high == yes)
    if_c		jmp	#.txempty		'wait until tx finished
    		wxpin   ##((23_400_000 * 64 / baud_rate)<<10 + 7), #tx_pin	'(23 MHz RCFAST)
    '		wxpin   ##((20_000_000 * 64 / baud_rate)<<10 + 7), #tx_pin	'(20 MHz XTAL)
    
    		drvl	#58
    
    .busyloop
    '
    'switch to RCFAST
    '
    		hubset	clk_mode		'switch to RCFAST before dismantling the PLL
    		hubset	#0
    '		hubset	##(1<<24 + _XPPPP<<4 + _XOSC<<2)	'switch to RCFAST before dismantling the PLL
    '		hubset	#_XPPPP<<4		'switch to RCFAST before dismantling the PLL
    '		hubset	#$f0			'switch to RCFAST, with clock glitch workaround
    '		hubset	#$f1			'switch to RCSLOW, with clock glitch workaround
    '		hubset	#($f2 + _XOSC<<2)	'switch to XTAL, with clock glitch workaround
    		getct	tickstart
    '		addct1	tickstart, ##230000	'10 ms  (23 MHz RCFAST)
    		addct1	tickstart, ##40000	'2 ms  (20 MHz XTAL)
    '
    'reporting
    '
    		mov	pa, #0
    		mov	cid, #15		'up to 16 cogs
    .cidloop
    		cogid	cid		wc	'cog active?
    		rcl	pa, #1			'note active state in PA
    		djnf	cid, #.cidloop
    
    		call	#itoh			'emit PA as hex
    		call	#putsp
    '
    'calculate/config new PLL settings
    '
    		getrnd	clk_mode
    '		and	clk_mode, #$0f		'range 15-30
    '		add	clk_mode, #15
    		and	clk_mode, #$1f		'range 2-33
    		add	clk_mode, #2
    
    		mov	sec, clk_mode
    		mul	sec, #500
    		mul	sec, ##1000		'(0.05 sec at new sysclock) x 1_000_000
    
    		sub	clk_mode, #1			'(_XMUL-1)<<8
    		shl	clk_mode, #8
    		add	clk_mode, ##(1<<24 + (_XDIV-1)<<18 + _XPPPP<<4 + _XOSC<<2)
    
    		waitct1				'allow time for PLL to wind down
    		mov	pa, clk_mode
    		or	pa, #_XSEL
    		hubset	clk_mode		'%0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' startup oscillator/PLL
    '		outnot	#58
    '		addct1	tickstart, ##92000	'4 ms  (23 MHz RCFAST)
    '		addct1	tickstart, ##80000	'4 ms  (20 MHz XTAL)
    '
    'switch to PLL
    '
    '		mov	pa, clk_mode
    '		or	pa, #_XSEL
    '		waitct1				'allow time for PLL to lock
    		hubset	pa			'%0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' engage oscillator/PLL
    '		outnot	#58
    '
    'burn some MIPS
    '
    		getct	tickstart
    		addct1	tickstart, sec
    .busywait
    		getrnd	rnd1
    		getrnd	rnd2
    		getrnd	rnd3
    		rep	@.rend, #10
    		qmul	rnd1, rnd2
    		mul	rnd1, cid
    		mul	rnd2, rnd3
    		mul	rnd3, cid
    .rend
    		jnct1	#.busywait		'keep busy until time
    		jmp	#.busyloop
    
    
    '------------------------------------------------------
    ORG
    multest
    		cogid	cid
    		add	cid, #54
    		drvl	cid
    		getrnd	cid
    
    .multloop
    		getrnd	rnd1
    		getrnd	rnd2
    		getrnd	rnd3
    		rep	@.rend, #10
    		qmul	rnd1, rnd2
    		mul	rnd1, cid
    		mul	rnd2, rnd3
    		mul	rnd3, cid
    .rend
    		jmp	#.multloop
    
    ORG 40
    cid		res	1
    rnd1		res	1
    rnd2		res	1
    rnd3		res	1
    
    
    640 x 480 - 19K
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanhevanh Posts: 6,643
    edited 2019-03-08 - 14:45:04
    Oops, spoke too early ...

    Okay, scrap that. It can run quite a while but does fail in the end. I started doing this trying to upset the FTDI chip again. Not having any luck there now either. I guess that's a good thing.

    Oh, scrap all that even more. It seems I wasn't giving the PLL/oscillator enough time (2 ms) to wind down after switching to RCFAST. If I increase the time then it goes splat on the first try. :(
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • jmgjmg Posts: 13,261
    evanh wrote: »
    ...
    Oh, scrap all that even more. It seems I wasn't giving the PLL/oscillator enough time (2 ms) to wind down after switching to RCFAST. If I increase the time then it goes splat on the first try. :(

    You will also be disabling the Xtal, and that does have a some-ms wind-up / wind-down time requirement.
    I've found that direct XTAL connect too soon can hang P2, and maybe enabling an unlocked PLL (no-xtal-yet) is also risky, as you do not really know what MHz that might be.

  • Ya, I was way too keen posting all that before running more tests. I didn't want to delete the hard work of typing it up though. :)
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
Sign In or Register to comment.