P2 - power cycle vs reset?
RossH
Posts: 5,462
in Propeller 2
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?
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?
Comments
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
- RES data defines not being initialised, and
- HUBSET instruction setting the sysclock without knowing prior config.
- 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.
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?
I don't use RES any more, for precisely this reason. I'll investigate your second suggestion.
I don't have a flash loader yet. But I will work on one.
I already execute following code on startup. Should this not be sufficient?
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).
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
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):
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.
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.
RossH, RES(erve) is safe to use. You just have to understand that the initial data states will be unknown.
The really strange part is that the same program runs perfectly well every second reset.
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)
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.
When you get to my age, forgetting the little things - like the wife's birthday or initializing variables - becomes a real problem
Did you see whether it has really locked up during that phase, by trying serial response '> d' or monitoring current?
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?
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.
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 ~”
Can you easily count the clocks on the SD CLK ? To see if that differs/alternates ?
http://forums.parallax.com/discussion/169608/prop2-flash-loader
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.
All my own fault! But I sure learned a lot along the way. Thanks all!
** 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
This sounds important, but it may as well be in greek for all it means to me! Can you elucidate?