Shop Learn P1 Docs P2 Docs
P2 Reset - possible problem - Page 3 — Parallax Forums

P2 Reset - possible problem

1356

Comments

  • evanhevanh Posts: 13,625
    Mark_T wrote: »
    The 3V3 dc converter has very little load normally, produces all sorts of unstable spurs till you pull some current
    from it (I've been running FFT testing a lot from smartpin ADC, this shows up the rail noise nicely if the pin is
    floating). Try adding 50mA load to the 3V3 line and see if it cleans up the rail and makes it more stable to
    sudden load change.

    Mark,
    Thank you for this. I've placed a 68 ohm resister across main capacitors, C707/C709 on output of the switcher circuit. I've got all the VIO jumpers back to the switcher and I/O clocking enabled as before. The picture is clean as.
    pin_lat0076.PNG
    640 x 480 - 9K
  • evanhevanh Posts: 13,625
    edited 2019-02-28 02:55
    That images is showing the whole sequence:
    - DTR reset.
    - Program download.
    - Normal 100 MHz with one cog testing the I/O. I/O clocking is progressively engaged across 62 pins at the middle where the current rises slightly (maybe 20 mA) before dropping back to 20 MHz RCFAST.
    - Reckless 100 MHz spike, then all 8 cogs running a tight loop of multiplies. I/O clocking still engaged.

    EDIT: That progression on the I/O clocking takes place over 5.3 ms, so isn't as long as I thought. The small rise in current draw has short time because the time consuming debug output is mostly before this.
  • jmgjmg Posts: 14,968
    evanh wrote: »
    Mark_T wrote: »
    The 3V3 dc converter has very little load normally, produces all sorts of unstable spurs till you pull some current
    from it (I've been running FFT testing a lot from smartpin ADC, this shows up the rail noise nicely if the pin is
    floating). Try adding 50mA load to the 3V3 line and see if it cleans up the rail and makes it more stable to
    sudden load change.

    Mark,
    Thank you for this. I've placed a 68 ohm resister across main capacitors, C707/C709 on output of the switcher circuit. I've got all the VIO jumpers back to the switcher and I/O clocking enabled as before. The picture is clean as.

    Many SMPS chips give a choice of light-load operation.
    You can run in forced PWM, which is less efficient at light loads, but is cleaner ( less ripple, higher frequency) as the switching is always (eg) 1MHz.
    Or, you can run in a sparse pulse mode, that kicks the inductor on an energy required basis.
    More efficient, but has rather higher ripple, and lower frequency and variable components due to the sparse kicks.

    hmm... The AOZ1284 info says "Under steady-state conditions, the converter operates in fixed frequency and Continuous-Conduction Mode (CCM)." which I thought meant fixed MHz ?

  • Cluso99Cluso99 Posts: 18,063
    @evanh
    Great detective work. I am using USB power on my P2-EVAL board.
    The switcher results are truly interesting.

    Looks like
    * a switcher down to say 3.8-4.0V and then LDO(s) to 3V3 and
    * a switcher down to say ~2V2 and then LDO(s) to 1V8
    would be the best mix for a high powered P2.

    Going to hope the respin P2 gets the power down significantly for most apps which will not push the P2 to its limits.
  • evanhevanh Posts: 13,625
    edited 2019-02-28 03:38
    Now I think about it, it was probably just a light duty mode for the regulator. Those pulses didn't show up that way at 350 MHz where the pins need a bit more juice. Like you say JMG, we were likely just seeing a slow top-up pulse. Probably nothing to worry about.

    EDIT: And 20 mA for clocked I/O at 100 MHz is on the mark from earlier measurements too. So, if anything did change with the stairs then it must have been the pulsing showing up there as well.

    EDIT2: I won't be removing that 68R resistor though. It's nicer not having to see those pulses.
  • jmgjmg Posts: 14,968
    Cluso99 wrote: »
    Going to hope the respin P2 gets the power down significantly for most apps which will not push the P2 to its limits.

    The peak variations may be worse on a clock-gated P2, which could give more crosstalk and PSU issues ...
    Cluso99 wrote: »
    @evanh
    Looks like
    * a switcher down to say 3.8-4.0V and then LDO(s) to 3V3 and
    * a switcher down to say ~2V2 and then LDO(s) to 1V8
    would be the best mix for a high powered P2.
    The 1v8 is more tolerant of supply noise than the 3v3 rail, so it's less important to have the LDO there.
    3v3 rails vary a lot in their use, so a mix of LDO and SMPS may be needed, depending on application ?

  • evanhevanh Posts: 13,625
    Since adding the resistor, I've done a long run, ~8000 cycles, of clocked I/O with normal PLL start-up. This has produced no USB lock-ups.

    I first did a shorter run, ~4000 cycles, of unclocked I/O with crazy PLL start-up. This also produced no USB lock-ups.

    Now starting a run of clocked I/O with crazy PLL start-up ...
  • evanhevanh Posts: 13,625
    edited 2019-02-28 12:46
    All good at 9000 cycles and counting ... A little surprised because I'm sure it did lock-up at least once since the resistor went in. Sadly I didn't have the scope armed at the time.

    Whether it's 100% or not, I have to admit it appears more stable than before.


    EDIT: Doing some speculating ... If this is the cause of the USB lock-ups then somehow the VIO switching regulator is stressing the FTDI chip causing it to fault out and create a bus wide shutdown on the USB side I guess.

    Only vaguely direct path is via Prop2 pins#62/63. I did feel I'd noted a correlation with a change I'd made to #62 at one stage. Any other path would have to go via the Common 5 Volt rail.
  • jmgjmg Posts: 14,968
    evanh wrote: »
    EDIT: Doing some speculating ... If this is the cause of the USB lock-ups then somehow the VIO switching regulator is stressing the FTDI chip causing it to fault out and create a bus wide shutdown on the USB side I guess.
    Only vaguely direct path is via Prop2 pins#62/63. I did feel I'd noted a correlation with a change I'd made to #62 at one stage. Any other path would have to go via the Common 5 Volt rail.
    That seems a stretch... but if it has improved, there must be some mechanism ?
    I guess there could be a ground loop at play here, is the 5V supply isolated and low noise ?
    Do you have a LDO on the VCO/PLL pins ?


  • evanhevanh Posts: 13,625
    LDO's are all unconnected since putting the resistor in.

    Benchtop supply is fully isolated. It has independent earth stud. Oscilloscope ground is earthed. USB ground is earthed via the desktop PC. All are powered from one mains circuit supplying this room. Only other powered devices in the room is network switch and ADSL modem/router.
  • jmgjmg Posts: 14,968
    edited 2019-03-01 03:42
    Attached is a scope grab of the AOZ1284 at light loads.

    It seems to give a kick of 3 full drive cycles, (here ~ 12KHz) then drops to a low-duty mode, then flips to what may be a special mode for BOOT cap charge?
    Notice to the left of the 3 drive pulses, the ringing and drive is not quite the same, as the low-duty drives to the right of the 3 drive pulses.
    That's a lot of ~10MHz ringing.
    The spacing of those full inductor kicks, will vary to suit the level of light load.
  • evanhevanh Posts: 13,625
    Just ticked over 31000 test cycles doing clocked I/O and crazy PLL startup. Not a single port open fail let alone a lockup,
  • jmgjmg Posts: 14,968
    evanh wrote: »
    Just ticked over 31000 test cycles doing clocked I/O and crazy PLL startup. Not a single port open fail let alone a lockup,
    Interesting. When it hits a larger number (50,000?) you could remove the 68R, and retest ?

  • evanhevanh Posts: 13,625
    edited 2019-03-01 04:18
    That's already plenty large enough. I am planning on pulling the resistor out when I get back tonight. Or more accurately, cut one leg.
  • evanhevanh Posts: 13,625
    edited 2019-03-01 09:31
    Ah, there we go. Of course, it's totally pin#62. I'd forgotten I'd made a specific change to pin#62 a while back. Namely, turning off the async serial smartpin mode just before running the crazy PLL code.

    I'm going to have to redo all the tests again. I get the feeling it's going to be much quicker results from now ...

    PS: I've just completed 6000 cycles of the prior test but with the resistor disconnected. Again, no issues at all.

    EDIT: And, having now removed the pin mode clearing code for pin#62, I've already had 3 port open failures in the first few minutes.

    EDIT:2: In hindsight I can see I'd not completed the testing of pin#62 when I had first suspected it.
  • jmgjmg Posts: 14,968
    evanh wrote: »
    Ah, there we go. Of course, it's totally pin#62. I'd forgotten I'd made a specific change to pin#62 a while back. Namely, turning off the async serial smartpin mode just before running the crazy PLL code.

    I'm going to have to redo all the tests again. I get the feeling it's going to be much quicker results from now ...

    PS: I've just completed 6000 cycles of the prior test but with the resistor disconnected. Again, no issues at all.

    EDIT: And, having now removed the pin mode clearing code for pin#62, I've already had 3 port open failures in the first few minutes.

    Trying to follow that .. ?
    Are you saying if you do not disable/re-enable the smart pin, that is somehow not reset correctly, and whatever it does during VCO lock, is enough to send the FTDI chip/driver out to lunch ?
    I thought a reset cleared all the registers, smart pins included ?
  • evanhevanh Posts: 13,625
    At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip. I'm not sure what else, if anything, is contributing just yet.

    I'll have to start over on all the combinations.
  • evanhevanh Posts: 13,625
    Reconnecting the resistor made no diff. ie: I'm reliably getting lock-ups again.
  • cgraceycgracey Posts: 13,795
    edited 2019-03-01 12:04
    evanh wrote: »
    At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip. I'm not sure what else, if anything, is contributing just yet.

    I'll have to start over on all the combinations.

    Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
  • evanhevanh Posts: 13,625
    Err, sorry, when I say lock-ups I mean a shutdown of all devices on that USB bus. It would be more accurate for me to say dead connection rather than lock-up.
  • evanhevanh Posts: 13,625
    It does look like the crazy PLL bashing is needed as well. I'm too tired to continue tonight.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,389
    edited 2019-03-01 18:56
    cgracey wrote:
    Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
    That's a known problem with the FTDI chips. Without a computer connected to the USB input, the Prop will parasitically power the FTDI chip when Tx goes high. That will cause a pulse on the DTR output, resetting the Prop, causing Tx to tri-state until the program starts again, ad infinitum. The solution is to buffer Tx and Rx against any backflow from the Prop. A less-desirable solution is to install pull-ups on Tx and Rx, so the FTDI chip is always parasitically powered, thus breaking the reset cycle.

    However, I do not know if this behavior is contributing to the issue being reported here.

    -Phil
  • jmgjmg Posts: 14,968
    edited 2019-03-01 19:11
    cgracey wrote: »
    Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
    I think both 5V sources are present, so there should be no power cycling at that time.
    evanh wrote: »
    At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip.
    ..
    It does look like the crazy PLL bashing is needed as well. I'm too tired to continue tonight.
    Possible pathways ?
    Could P2 emit some high baud rate ? I wonder if there is some phantom FTDI test mode path that is being triggered, where they use short pulses to enter it.
    Usually safe, in 99% of applications, until a MCU hits it with something above the data-sheet MAX baud speed ?
    Anything like that should be visible on a scope ?

    Or, maybe it is related to the peak current the crazy PLL passes thru, as it seeks lock.
    That could disturb either P2 smart pin or FTDI ?
    I notice the RX line from FTDI to P2 is quite long, and has a series 3k9 inserted , and going the other way P2 -> FTDI also as a 3k9, both with long traces.

    Maybe it's smarter to move the LEDs to lower port pins ? Those long traces are disturbing SD too... blinky leds are useful for early code testing, but hamper the higher speed pin-use.

    Addit: If you instead configure Tx smartpin as CMOS out, that's electrically the same as Smart-pin, but without the buried logic behind it. That may split smart-pin / external to smart pin ?
  • evanhevanh Posts: 13,625
    edited 2019-03-01 23:23
    Right, the USB 5 volts never goes away. It's one of the voltages I've been monitoring. EDIT2: Well, not until I power everything down to do the recovery.

    As far as I can remember, when clearing pin#62 pin mode, I had it config'd as an output. I'll give it another try anyway with both high and low steady ...

    EDIT: Yep, here's the now commented lines
    '		wrpin	#0, #tx_pin		'clear pin modes
    '		drvh	#tx_pin
    
  • evanhevanh Posts: 13,625
    edited 2019-03-01 23:28
    Oh, and here's what still exists just after the crazy PLL code ...
    		mov	pin, #55
    .unpins
    		dirl	pin			'un-AND
    		outl	pin			'un-AND
    		incmod	pin, #62	wz
    if_nz		jmp	#.unpins
    

    This might be more important, since pin#62 will continue to be an output as long and the smartpin stays configured. EDIT: The code for the pin mode changes had all been added at about the same time, when I decided to use the LEDs on the EVAL board to tell me when a cog has started up.

    I've now changed this to
    		incmod	pin, #61	wz
    
    and uncommented the earlier WRPIN/DRVH.
  • jmgjmg Posts: 14,968
    evanh wrote: »
    I've now changed this to
    		incmod	pin, #61	wz
    
    and uncommented the earlier WRPIN/DRVH.

    Interesting, I had assumed the incmod did what it says, which is a maths based modulus,

    Wiki says this about the math MOD operator
     For example, the modulo of powers of 2 can alternatively be expressed as a bitwise AND operation:
    
    x % 2n == x & (2n - 1)
    Examples (assuming x is a positive integer):
    
    x % 2 == x & 1
    x % 4 == x & 3
    x % 8 == x & 7
    

    If the second parameter is included in the range, that's not MOD, so maybe this is better called INCWRAP or similar ?

    Even that, is not quite exact, as the DOCs say this is the decision process

    "Increment with modulus. If D = S then D = 0 and C = 1, else D = D + 1 and C = 0. *"

    So it looks to be WRAPINC ? (Short for WRAP or INC) - ie the wrap test is done on the entry value, and if that fails to wrap, it increments.
  • looks to me like the second parameter is inclusive, that might explain some of my buffer failures.

    so a incmod x, 3 does

    0-1-2-3-0-1-2-3

    I was assuming 0-1-2-0-1-2

    RTFM, Mike

    Mike
  • jmgjmg Posts: 14,968
    msrobots wrote: »
    looks to me like the second parameter is inclusive, that might explain some of my buffer failures.

    so a incmod x, 3 does

    0-1-2-3-0-1-2-3

    I was assuming 0-1-2-0-1-2

    RTFM, Mike

    Mike

    Yes, I think many will not expect that, as that is NOT what the MOD operator does, so it really does need a rename, to avoid that natural confusion.
  • evanhevanh Posts: 13,625
    edited 2019-03-02 04:04
    11000 test cycles with pin#62 driven high - no port open errors, no lock-ups
    3000 test cycles with pin#62 driven low - no port open errors, no lock-ups

    What I've discovered though is that OUT and DIR registers of each cog are reset at COGINIT. Not so for a smartpin. A smartpin is only reset with the whole chip.

    PS: Just got something now that I'm driving pin#62 from the later COGINIT'd programs ...
  • evanhevanh Posts: 13,625
    edited 2019-03-02 05:29
    Confirmed. This is what I have so far:
    - Following a bad PLL setting
    - with pin#62 (Tx) driven, either high or low
    - and Prop2 is DTR reset
    - the subsequent program download has a small chance of failing to complete due to the USB bus shutting down every device on the bus at the end of that download.

    EDIT: In addition, although a USB shutdown (lock-up) can occur without a preceding port open error, the intermittent singular port open errors always foretell an impending USB shutdown. They are clearly another symptom. And part of this symptom is it always has a bump in the PC-USB 5 volt trace.
Sign In or Register to comment.