Shop OBEX P1 Docs P2 Docs Learn Events
P2 - power cycle vs reset? — Parallax Forums

P2 - power cycle vs reset?

I am seeing something odd on my P2 EVAL board - my programs work correctly every time if I power cycle the P2, but if I do a reset - either using the push button on the P2 EVAL board, or by toggling DTR on the Parallax Serial Terminal, then the same programs only work correctly every second time. This is perfectly consistent, and seems unrelated to the actual program.

What I am currently thinking is that doing a reset may leave some of the P2 smart pins in an undefined state, but they are reset by a power cycle - is this possible? Another possibility is that the SD card is left in an undefined state, but I have tried resetting it via CMD0 - makes no difference - and anyway this behaviour occurs even in programs that do not use the SD card.

Otherwise, what is different between power cycling the whole P2 board and doing a reset?
«1

Comments

  • jmgjmg Posts: 15,140
    Can you switch to boot from Flash, and recheck ?
    That should isolate the SD, which would be what I would suspect.
    The P2 reset pin, is hard-wired to all internal reset nodes, but SD reset's are more 'elastic' given various reports.
    I don't think there is an internal POR / dV/dT reset inside P2, it relies on P2 pin being LOW during Vdd ramp
  • evanhevanh Posts: 15,126
    A couple of sources of problems like that I've seen is:
    - RES data defines not being initialised, and
    - HUBSET instruction setting the sysclock without knowing prior config.
  • evanhevanh Posts: 15,126
    edited 2019-05-09 09:03
    Ah, another one is:
    - DIRL missing before a smartpin init. This particularly affects SPI clocking. I can't quite remember the detail, I think it was important to DIRH the clock pin after the data pin. But this only works if both were first DIRL'd.
  • Cluso99Cluso99 Posts: 18,066
    Ross,
    Also note that a reset does not clear cog/lut/ram but IIRC on powerup they are cleared. So perhaps your program is expecting variables to be initialised as zero???
  • RossHRossH Posts: 5,336
    Cluso99 wrote: »
    Ross,
    Also note that a reset does not clear cog/lut/ram but IIRC on powerup they are cleared. So perhaps your program is expecting variables to be initialised as zero???

    I thought of this one - so tried I manually zeroing all Hub RAM. Made no difference, so I don't think that's it. Also, why would it work every second time? :(
  • RossHRossH Posts: 5,336
    evanh wrote: »
    A couple of sources of problems like that I've seen is:
    - RES data defines not being initialised, and
    - HUBSET instruction setting the sysclock without knowing prior config.

    I don't use RES any more, for precisely this reason. I'll investigate your second suggestion.
  • RossHRossH Posts: 5,336
    jmg wrote: »
    Can you switch to boot from Flash, and recheck ?
    That should isolate the SD, which would be what I would suspect.
    The P2 reset pin, is hard-wired to all internal reset nodes, but SD reset's are more 'elastic' given various reports.
    I don't think there is an internal POR / dV/dT reset inside P2, it relies on P2 pin being LOW during Vdd ramp

    I don't have a flash loader yet. But I will work on one.
  • RossHRossH Posts: 5,336
    evanh wrote: »
    Ah, another one is:
    - DIRL missing before a smartpin init. This particularly affects SPI clocking. I can't quite remember the detail, I think it was important to DIRH the clock pin after the data pin. But this only works if both were first DIRL'd.

    I already execute following code on startup. Should this not be sufficient?
     mov dira, #0
     mov dirb, #0
    
  • Cluso99Cluso99 Posts: 18,066
    I seem to recall there was a hubset problem with resetting the clock incorrectly from what had been previously set. There was a very specific way required to reinitialise the clock. Take a look in both of the P2 Tricks and Traps threads (Reference and Discussions).
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-05-09 11:02
    There is an SD problem with the ROM code that can leave the SD driving the DO pin which blocks the Flash from executing. As there is a led on the SD DO pin P58, if you place a large pullup >20K (100K is better) on P58 you can tell if this is being drive by the SD card. This is fixed in the respin ROM. You can also fix this by driving SD CS P60=1 and toggling CLK P61 > 74 clock cycles.
    Worth a try too.

    BTW The SD Card doesn’t get reset by a reset signal. The only way to reset the SD is a power cycle if it gets into a lockup condition. The DO is not a lockup condition, but it does require the clocks to force the card to release DO. This is a problem with many, but not all brands.
    So a CMD0 must be preceeded by the 74 clocks at a slow pace -IIRC 50KHz (its commented in the ROM source).
  • TubularTubular Posts: 4,620
    edited 2019-05-09 12:41
    I need to physically pull the SD card (Samsung) out often when testing the with MicroPython. I believe the card gets into a state that affects the boot decisions. I haven't dug deeper yet.

    One thing worth trying is to see whether it has truly locked up, or still responds to autobaud ( "> esc" or "> d"). Watching the current should also reveal which path its going down. There is a timeout after 60 to 75 seconds before true shutdown.

    The other thing worth trying is a sandisk ultra (red and grey) sd card. These behave differently to the other brands I've tested, and I think thats what Cluso used for his testing. While they don't release the SO line without an extra clock or two, they do succeed at pushbutton/dtr boots the second time through, for whatever reason.

    I intend to hook up a high impedance buffer on the 4 boot related signals. The trouble with cmos inputs is the load of a cro probe can be enough to make the input change state, as can nearby signals
  • evanhevanh Posts: 15,126
    RossH wrote: »
    I already execute following code on startup. Should this not be sufficient?
     mov dira, #0
     mov dirb, #0
    
    Cool, that'll do the job as long as there is no other uses of the relevant pins in between.

  • evanhevanh Posts: 15,126
    Attached is complete example of the sysclock setting code (in the _diaginit routine) in an up-to-date revision of my testing that happens to also be printing out the decoded values. When I started this I was pondering what could be done for auto selecting a clock config but never got back to it.

    Here's the crux of what's important about making a change to the config (ie: The first HUBSET needs to use prior config but with bottom two bits as %00 to cleanly switch to RCFAST as the first step):
    		hubset	clk_mode			'switch to RCFAST using known prior mode
    		mov	clk_mode, ##SETFREQ		'replace old with new
    		mov	clk_freq, ##CLOCKFREQ		'optional, if clk_freq used
    		hubset	clk_mode			'setup for new mode, still RCFAST
    		waitx	##20_000_000/100		'~10ms for crystal/PLL to come up to speed
    		hubset	##ENAFREQ			'engage
    
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    Also note that a reset does not clear cog/lut/ram but IIRC on powerup they are cleared.
    ? I don't think any RAM in P2 is cleared on powerup.
    Memory with reset needs extra silicon, and reset and powerup are the same on P2.
    Software could clear any amount of RAM, but that's not a HW operation.

    Cluso99 wrote: »
    I seem to recall there was a hubset problem with resetting the clock incorrectly from what had been previously set. There was a very specific way required to reinitialise the clock.
    Yes, see above example from evanh, that issue was only for 'live' changes, you need to avoid possible PLL lockouts, by venturing into no-mans-land :)
    Coming out of reset is always RST -> RCFAST to boot, then users can change at will.

  • cgraceycgracey Posts: 14,133
    All flops get cleared on reset. The only uknown states are in the RAMs.

    RossH, RES(erve) is safe to use. You just have to understand that the initial data states will be unknown.
  • RossHRossH Posts: 5,336
    Thanks for all the suggestions. Not solved yet, but I am learning a lot! :)

    The really strange part is that the same program runs perfectly well every second reset. :(
  • jmgjmg Posts: 15,140
    RossH wrote: »
    jmg wrote: »
    Can you switch to boot from Flash, and recheck ?
    ...

    I don't have a flash loader yet. But I will work on one.

    The P2 bootloader can pgm the flash, via a choice of PC downloaders. There is a python one that is quite simple.
    https://forums.parallax.com/discussion/168850/python-p2-loader/p1
    Maybe the text on that first post needs revising, as the attached code is at v1.2, and is a bit more advanced than 'a starting point' might indicate :)
    ie It has been speed-tuned, and P2 proven, and works surprisingly well. (I had expected Python to include speed compromises, but the right libraries helps)
    RossH wrote: »
    ...
    The really strange part is that the same program runs perfectly well every second reset. :(
    That's where a flash-boot step would be a useful test point, as that should isolate SD card reset issues.
  • RossHRossH Posts: 5,336
    jmg wrote: »
    RossH wrote: »
    jmg wrote: »
    Can you switch to boot from Flash, and recheck ?
    ...

    I don't have a flash loader yet. But I will work on one.

    The P2 bootloader can pgm the flash, via a choice of PC downloaders. There is a python one that is quite simple.
    https://forums.parallax.com/discussion/168850/python-p2-loader/p1
    Maybe the text on that first post needs revising, as the attached code is at v1.2, and is a bit more advanced than 'a starting point' might indicate :)
    ie It has been speed-tuned, and P2 proven, and works surprisingly well. (I had expected Python to include speed compromises, but the right libraries helps)
    RossH wrote: »
    ...
    The really strange part is that the same program runs perfectly well every second reset. :(
    That's where a flash-boot step would be a useful test point, as that should isolate SD card reset issues.

    Thanks. I will try the flash loader.
  • RossHRossH Posts: 5,336
    cgracey wrote: »
    All flops get cleared on reset. The only uknown states are in the RAMs.

    RossH, RES(erve) is safe to use. You just have to understand that the initial data states will be unknown.

    When you get to my age, forgetting the little things - like the wife's birthday or initializing variables - becomes a real problem :)
  • What SD card (brand, type) are you using Ross?

    Did you see whether it has really locked up during that phase, by trying serial response '> d' or monitoring current?

  • RossHRossH Posts: 5,336
    jmg wrote: »
    RossH wrote: »
    jmg wrote: »
    Can you switch to boot from Flash, and recheck ?
    ...

    I don't have a flash loader yet. But I will work on one.

    The P2 bootloader can pgm the flash, via a choice of PC downloaders. There is a python one that is quite simple.
    https://forums.parallax.com/discussion/168850/python-p2-loader/p1
    Maybe the text on that first post needs revising, as the attached code is at v1.2, and is a bit more advanced than 'a starting point' might indicate :)
    ie It has been speed-tuned, and P2 proven, and works surprisingly well. (I had expected Python to include speed compromises, but the right libraries helps)
    RossH wrote: »
    ...
    The really strange part is that the same program runs perfectly well every second reset. :(
    That's where a flash-boot step would be a useful test point, as that should isolate SD card reset issues.

    Hmmm. I'm not a python person. All I get is
    Scanning ports....
    COM10 = Traceback (most recent call last):
      File "P2Eval_loader_1.2.py", line 159, in <module>
        find_p2()
      File "P2Eval_loader_1.2.py", line 118, in find_p2
        sp.open()
      File "C:\Users\User\AppData\Local\Programs\Python\Python37\lib\site-packages\s
    erial\serialwin32.py", line 62, in open
        raise SerialException("could not open port {!r}: {!r}".format(self.portstr,
    ctypes.WinError()))
    serial.serialutil.SerialException: could not open port 'COM10': PermissionError(
    13, 'Access is denied.', None, 5)
    

    Which is fair enough, because I don't actually have a COM10 :(

    In any case, I can't see any code in there to program the flash RAM. It just seems to do a serial load, which I can already do.

    Am I missing something?
  • RossHRossH Posts: 5,336
    Tubular wrote: »
    What SD card (brand, type) are you using Ross?

    Did you see whether it has really locked up during that phase, by trying serial response '> d' or monitoring current?

    It may indeed be an SD card lockup, but there's not much I can do about that, since that code is part of the boot loader. My program doesn't actually use the SD card - it is just loaded from it. But the really confusing bit is that it actually loads and runs every time, but it only runs correctly every second time.

    I can't think of an explanation for that :(

    BTW my SD Card is a SanDisk 8GB.
  • jmgjmg Posts: 15,140
    RossH wrote: »
    In any case, I can't see any code in there to program the flash RAM. It just seems to do a serial load, which I can already do.

    Am I missing something?
    Oops, yes, the ROM loader loads RAM, and it is another step to program flash, as I think the decision was made to make ROM loader a read-only operation, so as not to lock to any brand/longevity of Flash-write.
    That means a small stub is needed to pgm flash, tho TAQOZ may be able to do this ?

    However, if you can load RAM, you should be able to test reset issues.

    Looking again at the Python code, I notice it bumps up the SysCLK to download faster, and does not restore, which may not be the best idea (given the clkset issues above).

    Better may be to either
    a) Add option to skip CLK boost step, to cover more testing choices ( download is 1~2MB max on RCFAST ?)
    or
    b) add lines to go back to RCFAST, (the usual reset default) and Autobaud again, just before the line
    sp.write(b'~') #run
    which means a user pgm will launch the same as if it had exited reset directly.
    (well, almost, the UART smart pins are initialised by the loader to communicate, then the loader executes reset_pins)

    I wonder what the shortest reset/run command is ?
    Is this legal ? (ie no actual hex block, just the run suffix)
    pulse DTR,pause, send “> Prop_Hex 0 0 0 0 ~”
  • jmgjmg Posts: 15,140
    RossH wrote: »
    .. But the really confusing bit is that it actually loads and runs every time, but it only runs correctly every second time.
    How different as 'loads and runs' and 'loads and runs correctly' ?
    Can you easily count the clocks on the SD CLK ? To see if that differs/alternates ?

  • evanhevanh Posts: 15,126
    Stability of the 5 volt supply can be another line of attack. The PC-USB 5 volts is a known weak supply. The next rev of the EVAL board has done away with the wimpy poly fuse to rectify this issue.

    Basically, make sure there is a strong AUX 5 volt supply. Either from the P2-USB or the AUX pins.

    And then there is another issue where the AUX USB switch can fail too. Not sure why this happens but it's permanent, so you haven't hit this one yet.
  • evanhevanh Posts: 15,126
    edited 2019-05-10 06:54
    Actually, bridging the poly fuse might be the best solution. Certainly best to try this before the AUX switch fails. Once the AUX switch fails the power controls are disabled.
  • RossHRossH Posts: 5,336
    edited 2019-05-10 07:11
    Found it! It was due to some uninitialized Hub RAM. The first time the program ran, it looked like it was working, but it also set the RAM location to a value that made it guaranteed to fail on the next load. Just coincidentally, when it then failed, it also set the RAM location back to a value that made the program work again on the next load! **

    All my own fault! But I sure learned a lot along the way. Thanks all! :blush:

    ** I thought I had eliminated this possibility by zeroing the Hub RAM between each load. But I must not have done this correctly, so I ended up going down several blind alleys :(
  • RossHRossH Posts: 5,336
    evanh wrote: »
    Actually, bridging the poly fuse might be the best solution. Certainly best to try this before the AUX switch fails. Once the AUX switch fails the power controls are disabled.

    This sounds important, but it may as well be in greek for all it means to me! Can you elucidate?
  • evanhevanh Posts: 15,126
    edited 2019-05-10 08:10
    I've drawn a red line to represent where the bridging link is needed. This bypasses F401, the poly fuse, on the PC-USB 5 volt supply.
    poly%20fuse%203D%20Preview.png
    726 x 604 - 73K
Sign In or Register to comment.