Shop OBEX P1 Docs P2 Docs Learn Events
P2 Reset - possible problem - Page 5 — Parallax Forums

P2 Reset - possible problem

1235

Comments

  • jmgjmg Posts: 15,140
    All good, no problems. .

    evanh's comments suggest PPPP change is key - do any of those TAQOZ tests change PPPP ?

  • jmg wrote: »
    All good, no problems. .

    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.
  • jmg wrote: »
    cheezus wrote: »
    evanh wrote: »
    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!!
  • evanhevanh Posts: 15,091
    edited 2019-03-07 00:43
    cgracey wrote: »
    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.
  • jmgjmg Posts: 15,140
    cheezus wrote: »
    jmg wrote: »
    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.
    cheezus wrote: »
    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 ?

  • evanhevanh Posts: 15,091
    cheezus wrote: »
    So, if we're running off xtal+pll and then reload a program that begins with hubset #0 it could crash?
    Yes, that's the very issue.
  • evanhevanh Posts: 15,091
    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.

    No issues!

    Bear in mind these values encode to %PPPP of:
     1 => %1111
     2 => %0000
     4 => %0001
     6 => %0010
     8 => %0011
    10 => %0100
    12 => %0101
    14 => %0110
    16 => %0111
    18 => %1000
    20 => %1001
    22 => %1010
    24 => %1011
    26 => %1100
    28 => %1101
    30 => %1110
    
  • cgraceycgracey Posts: 14,131
    edited 2019-03-07 02:09
    evanh wrote: »
    cgracey wrote: »
    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.

    2434 x 1233 - 56K
  • evanhevanh Posts: 15,091
    edited 2019-03-07 06:35
    You already know the solution that I'd like. :P

    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

  • cgraceycgracey Posts: 14,131
    Well, is there IS or is there AIN'T a problem?
  • evanhevanh Posts: 15,091
    edited 2019-03-07 02:32
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    You already know the solution that I'd like. :P

    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 ?

  • evanhevanh Posts: 15,091
    edited 2019-03-07 06:35
    jmg wrote: »
    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.

    Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?

  • jmgjmg Posts: 15,140
    edited 2019-03-07 02:52
    evanh wrote: »
    jmg wrote: »
    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

  • cheezuscheezus Posts: 295
    edited 2019-03-07 02:50
    evanh wrote: »
    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.
  • evanhevanh Posts: 15,091
    edited 2019-03-07 06:34
    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
    


    Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494

  • cgraceycgracey Posts: 14,131
    edited 2019-03-07 04:31
    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.
  • evanhevanh Posts: 15,091
    edited 2019-03-07 04:29
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?
  • evanhevanh Posts: 15,091
    This was always about re-selecting a new clock frequency after the PLL had already been setup by something else.
  • evanhevanh Posts: 15,091
    edited 2019-03-07 06:33
    jmg wrote: »
    ie Any code that may reenter, should use these config patch workarounds ?
    Yes, it's the safe solution. Place it where HUBSET #0 had been used.

    Chip has given new guidance - https://forums.parallax.com/discussion/comment/1466494/#Comment_1466494

  • evanhevanh Posts: 15,091
    Fastspin should add it to clkset().
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-03-07 04:44
    evanh wrote: »
    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#
    

  • cgraceycgracey Posts: 14,131
    edited 2019-03-07 04:55
    jmg wrote: »
    evanh wrote: »
    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.
  • evanhevanh Posts: 15,091
    Peter,
    It doesn't fail every time every time. Maybe 10%.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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.
  • evanhevanh Posts: 15,091
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-03-07 05:00
    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.
  • cgraceycgracey Posts: 14,131
    edited 2019-03-07 05:06
    evanh wrote: »
    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.
Sign In or Register to comment.