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 �
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#
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 ?
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.
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
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.
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
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
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.
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.
...
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.
Comments
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.
But then I did this another couple of times:
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.
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
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 ?
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.
"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.
That's right!
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.
And the source for the test loop
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.
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.