So all those programs that start with a HUBSET #0 are possibly at risk.
Could this explain the need for cold resets while testing SD cards? It seemed like the chip wasn't fully resetting, although I wrote it up to SD card lockup. For example, when trying to upload another program, while still running a previous program, the new program would never function correctly but would run fine from a freshly reset P2.
So, if we're running off xtal+pll and then reload a program that begins with hubset #0 it could crash?
I think evanh is saying if the PPPP changes (VCO post divider), yes.
Did your test programs change the VCO divider away from the default /1 ? ie what was the VCO set to run at before/after your own system reload ?
It sounds like this isn't the issue, since a reset should switch over to RCFAST from whatever clock settings were configured previously. The clock change sequence would be RCFAST -> xtal+pll -> RESET, goes back to RCFAST and so on. I was wondering if the boot code's initial HUBSET could be hanging the chip but as long as the reset circuit is doing it's job properly it can't be an issue.
I've been using the post divider for MHz compatibility testing setting pll @ 320 and getting my standard 160mhz from /2. Then I can slow things down to /4 or /8 so the logic analyzer can keep up. What I still can't understand is the need for power cycling when I run some faulty code. The same SD card seemed tolerant of warm - reset in P1 card crashing situations.
I'm going to continue chalking this up to P2 noob issues, but detailing clock changing procedure is going to be important!!
If you are switching away from the crystal+PLL to the internal RCFAST oscillator, you'd want to first change the two LSB's to %00 via HUBSET to switch from the PLL to the RCFAST oscillator, then you could do a HUBSET #0 to shut off the crystal+PLL, while remaining in RCFAST.
Chip,
I'm going to assume that wasn't intended. That tells me a config line for clock source, separate from PLL config, would have been the best approach.
I think evanh is saying if the PPPP changes (VCO post divider), yes.
Did your test programs change the VCO divider away from the default /1 ? ie what was the VCO set to run at before/after your own system reload ?
It sounds like this isn't the issue, since a reset should switch over to RCFAST from whatever clock settings were configured previously. The clock change sequence would be RCFAST -> xtal+pll -> RESET, goes back to RCFAST and so on. I was wondering if the boot code's initial HUBSET could be hanging the chip but as long as the reset circuit is doing it's job properly it can't be an issue.
That's a slightly different pathway, and issue.
A physical reset does a reset of all flops/registers and enables RCFAST, so even if P2 has hung on the leading edge, the reset state has plenty of clocks to assert things, including the PC, to a stable state.
Reset release is then clean, using RCFAST.
For example, I can certainly exit a XTAL-select-induced-Hang, using a physical reset.
I've been using the post divider for MHz compatibility testing setting pll @ 320 and getting my standard 160mhz from /2. Then I can slow things down to /4 or /8 so the logic analyzer can keep up. What I still can't understand is the need for power cycling when I run some faulty code. The same SD card seemed tolerant of warm - reset in P1 card crashing situations.
I'm going to continue chalking this up to P2 noob issues, but detailing clock changing procedure is going to be important!!
You seem to be meeting the PPPP change requirement ?
You could try /1, and see if that has any effect on SD stability ?
I've just been testing out different %PPPP values for each run of the PLL config, and then hitting it directly with a HUBSET #0, ie: the old way. So far, other than my original value of 1, I've tried _XPPPP values of 2, 4, 6, 8, 10, 12 and 14.
If you are switching away from the crystal+PLL to the internal RCFAST oscillator, you'd want to first change the two LSB's to %00 via HUBSET to switch from the PLL to the RCFAST oscillator, then you could do a HUBSET #0 to shut off the crystal+PLL, while remaining in RCFAST.
Chip,
I'm going to assume that wasn't intended. That tells me a config line for clock source, separate from PLL config, would have been the best approach.
I was wrong about how it works. I just got new license strings and I couldn't get into the schematic software until after an hour of wrangling with the license configurator. This dongle stuff gives me grief whenever it rears its head.
Anyway, the way the clock switcher works is that when you switch clock sources, it freezes the current clock state and waits for a transition to that same state from the new clock source, then switches over to it. So, I'm not sure why we're seeing anything problematic.
If there's something necessitating power cycling to get the P2 running again, we have a problem that needs addressing, quick. Now's the time to figure it out!!!
Here is the schematic for the clock mux/deglitcher.
However, it looks like there is a solid workaround: Use HUBSET #$f0 instead of #0 to select RCFAST.
EDIT: For RCSLOW use HUBSET #$f1. Not sure about XI source.
The problem is solely with switching away from %PPPP == %1111.
PS: I've only just tested for this. So latest info. Just testing the final couple remaining right now.... completed. Yep, I'm satisfied I've narrowed it down to this.
However, it looks like there is a solid workaround: Use HUBSET #$f0 instead of #0 to select RCFAST.
EDIT: For RCSLOW use HUBSET #$f1. Not sure about XI source.
So that rule presumes you started with PPPP = 1111, (/1) and thus does not change PPPP during the source switch ?
If you had instead used PPPP= 0000 (/2) then is HUBSET #0 then more correct ?
Anyway, the way the clock switcher works is that when you switch clock sources, it freezes the current clock state and waits for a transition to that same state from the new clock source, then switches over to it. So, I'm not sure why we're seeing anything problematic.
If there's something necessitating power cycling to get the P2 running again, we have a problem that needs addressing, quick. Now's the time to figure it out!!!
Here is the schematic for the clock mux/deglitcher.
There are issues if you select XTAL too soon, so that suggests narrow or incomplete clock pulses could disturb P2.
The SCH you have there, has DLY16 elements (delay lines ? what duration ? )
They seem to reset FF on change of bits, but change the MUX on the trailing (delayed) edge ?
Seems to have scope to let thru very narrow clock pulses, when hopping between 2 async sources ?
If you had instead used PPPP= 0000 (/2) then is HUBSET #0 then more correct ?
That works no issue. But so does HUBSET #$f0, and happens to work in all cases.
So it is a problem going /1 -> /2, but you can do /2 -> /1 ok during the switch over, and /1 -> /1 is also ok ?
That /1 to /2N case is likely to have fishhooks, as there is a skew between the CLK and divider outputs. The 2N cases (2..30) I'd expect to have 'same' delays.
A change of PPPP also does not seem to trigger Chip's clock-handover, even tho it will cause a significant change in clock.
Chip's clock handover handler looks to trigger on any changes in only the SS bits
The problem is solely with switching away from %PPPP == %1111.
PS: I've only just tested for this. So latest info. Just testing the final couple remaining right now.... completed. Yep, I'm satisfied I've narrowed it down to this.
This would line up with one of my phantom testing issues, where sometimes things wouldn't work. It would make sense the power cycling issue started about the time I started doing my own clock config. I've been defaulting to post div /2 but testing at /1 and seemed stable. But after all my /1 testing I pulled the plug due to thermal concerns. So I was ready to dismiss my issue as programmer error.
Switching between PPPP=%1111 and any other PPPP value is problematic, actually. The mux/deglitcher does not come into play in that case, since CFG[1:0] remain still at %11, and you are not just changing the post-divider value, but a special mux that selects between VCO-direct and VCO-divided.
To safely switch between PPPP=%1111 and some other PPPP value, you'll need to switch CFG[1:0] away from the PLL (%11) to any other source, then set the PLL configuration, and then switch back to it.
And, of course, don't switch to crystal or PLL before they have had time to stabilize.
At any rate, no misconfiguration should ever require a power cycle to recover from.
Sorry, I wasn't detailed there Chip. When I say away from %1111, I meant in the same config as RCFAST selection, for example. Eg: $xxxxxxFB => $00 doesn't work. Where as $EB => $00 works fine. And $xB => $F0 works for all.
Here's the three non-PLL source selects (with workaround config bits):
' 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
So those apply going from a PLL/VCO source (any setting) going over to any of the 3 other choices.
ie Any code that may reenter, should use these config patch workarounds ?
Sorry, I wasn't detailed there Chip. When I say away from %1111, I meant in the same config as RCFAST selection, for example. Eg: $xxxxxxFB => $00 doesn't work. Where as $EB => $00 works fine. And $xB => $F0 works for all.
Isn't that what I was doing before?
TAQOZ# CRUISE 0 HUBSET CRUISE --- ok
TAQOZ# _clk @ .L --- $0100_0EFB ok
So I switch from a $0100_0EFB mode to $00 and back again.
Also tested staying in RCFAST and then switching back. (RCFAST is set and known to be 22.4MHz in my P2)
TAQOZ# RCFAST --- ok
TAQOZ# .CLK --- 22,400,000Hz ok
TAQOZ# CRUISE --- ok
TAQOZ# .CLK --- 180MHz ok
TAQOZ#
Here's the three non-PLL source selects (with workaround config bits):
' 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
So those apply going from a PLL/VCO source (any setting) going over to any of the 3 other choices.
ie Any code that may reenter, should use these config patch workarounds ?
You should be able switch away from *any* PLL setting (%11) to crystal (%10), RCSLOW (%01), or RCFAST (%00), as long as you don't also switch PPPP to or from %1111, since that VCO-direct/divided mux might glitch before the main clock mux can do its safe switch-over.
On the other hand, you can freely switch among PLL settings with the PLL selected, as long as you don't switch to or from PPPP=%1111. So, changing the three divider values is okay during PLL operation. The only thing you need to watch out for is VCO-frequency overshoot, which could cause too small of a clock pulse. So, the only fully-safe switching you can do is to change PPPP between values 0000 and 1110, since that does not affect VCO frequency, nor change the VCO-direct/divided mux.
A good rule of thumb could simply be to make any PLL adjustments outside of PLL mode (%11), and allow for any time needed for VCO frequency settling, before switching back to PLL mode.
You should be able switch away from *any* PLL setting (%11) to crystal (%10), RCSLOW (%01), or RCFAST (%00), as long as you don't also switch PPPP to or from %1111, since that VCO-direct/divided mux might glitch before the main clock mux can do it's safe switch-over.
I think evanh is saying that switching PPPP to %1111 is ok, seems the glitch is limited to going the other way.
Since it is so quick to torture test it, I did this:
TAQOZ# 16 0 DO I PLLDIV CLKSET 0 HUBSET LOOP CRUISE --- ok
TAQOZ# --- ok
TAQOZ# 100 FOR 16 0 DO I PLLDIV CLKSET 0 HUBSET LOOP NEXT CRUISE --- ok
TAQOZ#
PLLDIV sets the PPPP field in my _clk variable and CLKSET simply reads that variable, does a backup and then a HUBSET with it.
The first line went through all possible values from 0 to 15 (until it reached 16) and after a HUBSET it also writes a 0 to HUBSET.
The second line said do this for 100 times.
All I'm saying is that I haven't been able to make it play up yet.
I may have lucked on that one JMG. But it does seem to be reliable. The alternative would be knowing the prior config and reusing it.
Yes, that happened to be copacetic with the hardware, but I wouldn't have guessed it would be.
The conservative thing to do is track what value was last written and not change those upper bits, while you change the lower two bits, only. This means that any hub memory usage scheme should make accommodation for the last HUBSET value written. If you don't know that value, you cannot safely switch away from a potential PLL mode. What Evanh lucked upon is maybe a sufficient trick, but it's only by virtue of subtlety in the hardware implementation that it works. Good job finding that!
That VCO-direct/divided mux was not part of the original design, but was implemented when we realized that we could not have the VCO dividers running at 2x speed for the fast cases.
Comments
evanh's comments suggest PPPP change is key - do any of those TAQOZ tests change PPPP ?
Thanks for pointing that out, I will do some tests very shortly on the eval board with this in mind.
It sounds like this isn't the issue, since a reset should switch over to RCFAST from whatever clock settings were configured previously. The clock change sequence would be RCFAST -> xtal+pll -> RESET, goes back to RCFAST and so on. I was wondering if the boot code's initial HUBSET could be hanging the chip but as long as the reset circuit is doing it's job properly it can't be an issue.
I've been using the post divider for MHz compatibility testing setting pll @ 320 and getting my standard 160mhz from /2. Then I can slow things down to /4 or /8 so the logic analyzer can keep up. What I still can't understand is the need for power cycling when I run some faulty code. The same SD card seemed tolerant of warm - reset in P1 card crashing situations.
I'm going to continue chalking this up to P2 noob issues, but detailing clock changing procedure is going to be important!!
I'm going to assume that wasn't intended. That tells me a config line for clock source, separate from PLL config, would have been the best approach.
A physical reset does a reset of all flops/registers and enables RCFAST, so even if P2 has hung on the leading edge, the reset state has plenty of clocks to assert things, including the PC, to a stable state.
Reset release is then clean, using RCFAST.
For example, I can certainly exit a XTAL-select-induced-Hang, using a physical reset.
You seem to be meeting the PPPP change requirement ?
You could try /1, and see if that has any effect on SD stability ?
No issues!
Bear in mind these values encode to %PPPP of:
I was wrong about how it works. I just got new license strings and I couldn't get into the schematic software until after an hour of wrangling with the license configurator. This dongle stuff gives me grief whenever it rears its head.
Anyway, the way the clock switcher works is that when you switch clock sources, it freezes the current clock state and waits for a transition to that same state from the new clock source, then switches over to it. So, I'm not sure why we're seeing anything problematic.
If there's something necessitating power cycling to get the P2 running again, we have a problem that needs addressing, quick. Now's the time to figure it out!!!
Here is the schematic for the clock mux/deglitcher.
However, it looks like there is a solid workaround: Use HUBSET #$f0 instead of #0 to select RCFAST.
EDIT: For RCSLOW use HUBSET #$f1. Not sure about XI source.
Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494
PS: I've only just tested for this. So latest info. Just testing the final couple remaining right now.... completed. Yep, I'm satisfied I've narrowed it down to this.
If you had instead used PPPP= 0000 (/2) then is HUBSET #0 then more correct ?
Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494
The SCH you have there, has DLY16 elements (delay lines ? what duration ? )
They seem to reset FF on change of bits, but change the MUX on the trailing (delayed) edge ?
Seems to have scope to let thru very narrow clock pulses, when hopping between 2 async sources ?
So it is a problem going /1 -> /2, but you can do /2 -> /1 ok during the switch over, and /1 -> /1 is also ok ?
That /1 to /2N case is likely to have fishhooks, as there is a skew between the CLK and divider outputs. The 2N cases (2..30) I'd expect to have 'same' delays.
A change of PPPP also does not seem to trigger Chip's clock-handover, even tho it will cause a significant change in clock.
Chip's clock handover handler looks to trigger on any changes in only the SS bits
This would line up with one of my phantom testing issues, where sometimes things wouldn't work. It would make sense the power cycling issue started about the time I started doing my own clock config. I've been defaulting to post div /2 but testing at /1 and seemed stable. But after all my /1 testing I pulled the plug due to thermal concerns. So I was ready to dismiss my issue as programmer error.
Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494
To safely switch between PPPP=%1111 and some other PPPP value, you'll need to switch CFG[1:0] away from the PLL (%11) to any other source, then set the PLL configuration, and then switch back to it.
And, of course, don't switch to crystal or PLL before they have had time to stabilize.
At any rate, no misconfiguration should ever require a power cycle to recover from.
So those apply going from a PLL/VCO source (any setting) going over to any of the 3 other choices.
ie Any code that may reenter, should use these config patch workarounds ?
Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494
Isn't that what I was doing before? So I switch from a $0100_0EFB mode to $00 and back again.
Also tested staying in RCFAST and then switching back. (RCFAST is set and known to be 22.4MHz in my P2)
You should be able switch away from *any* PLL setting (%11) to crystal (%10), RCSLOW (%01), or RCFAST (%00), as long as you don't also switch PPPP to or from %1111, since that VCO-direct/divided mux might glitch before the main clock mux can do its safe switch-over.
On the other hand, you can freely switch among PLL settings with the PLL selected, as long as you don't switch to or from PPPP=%1111. So, changing the three divider values is okay during PLL operation. The only thing you need to watch out for is VCO-frequency overshoot, which could cause too small of a clock pulse. So, the only fully-safe switching you can do is to change PPPP between values 0000 and 1110, since that does not affect VCO frequency, nor change the VCO-direct/divided mux.
A good rule of thumb could simply be to make any PLL adjustments outside of PLL mode (%11), and allow for any time needed for VCO frequency settling, before switching back to PLL mode.
It doesn't fail every time every time. Maybe 10%.
I think evanh is saying that switching PPPP to %1111 is ok, seems the glitch is limited to going the other way.
The first line went through all possible values from 0 to 15 (until it reached 16) and after a HUBSET it also writes a 0 to HUBSET.
The second line said do this for 100 times.
All I'm saying is that I haven't been able to make it play up yet.
Yes, that happened to be copacetic with the hardware, but I wouldn't have guessed it would be.
The conservative thing to do is track what value was last written and not change those upper bits, while you change the lower two bits, only. This means that any hub memory usage scheme should make accommodation for the last HUBSET value written. If you don't know that value, you cannot safely switch away from a potential PLL mode. What Evanh lucked upon is maybe a sufficient trick, but it's only by virtue of subtlety in the hardware implementation that it works. Good job finding that!
That VCO-direct/divided mux was not part of the original design, but was implemented when we realized that we could not have the VCO dividers running at 2x speed for the fast cases.