P2 Software Reset
ke4pjw
Posts: 1,155
in Propeller 2
Is it possible to perform a reset on the P2 from software?
Comments
Yes.
The short answer for the P2 itself is "Yes" - see the Hard Reset option to the HUBSET instruction.
However, the long answer is that this may not be enough, depending on what you are trying to accomplish and your hardware configuration. For instance, it is possible to get SPI peripherals connected to the P2 (such as SD Cards) into a state where only a card removal/reinsertion or power cycle can get you out.
Ross.
FlexBasic has "_Reboot"
@Rossh I think you are right, but is this only because our drivers are missing features?
I think this may be something I am seeing with my light controller. The hardware reset does not work, and now that I think about it, it could be hanging when mounting the SD card after reset. (I have not investigated) I thought that issue only occurred if you were using the faster modes, instead of just straight SPI.
With a software reset, I think I can dismount the SD card before calling the HUBSET ##$1000_0000 and it will take care of that problem.
I played around with my 4-SD Card RAISD for P1 some years ago and stumbled over this issue too.
Tried all I can think of, unmounting, extra clocks whatever I could think of.
To no avail.
The only solution seems to be to cut power to the card to reset it.
@rogloh made some board for 4-bit sd and included some power switching of SD and I think this should be followed.
Mike
No, I don't think so. I read somewhere online that it is a known problem with some SD card implementations. Should have kept the link. If I can find it again I will post it.
Was looking around and found someone saying to just send $FF repeatedly until it replies with $FF.
I assume that’s been tried already, right?
SD cards can go into an "inactive" state in some cases if they receive invalid requests for the current state they are in, although I thought this mainly would be when in SD mode, not SPI mode (but I might be wrong). Once they are in this state they need to be power cycled to exit it (either yank the card or remove power from the card reader).
Yes, I played around with that a while ago - it didn't seem to make any difference. However,I haven't re-tried this since I found and fixed an unrelated bug in the SD Card driver, so I should try it again.
Ross.
From Spec:
Notably, if ACMD41 is executed out of order, or mismatched parameter, in SD mode then the card will default to inactive.
And, correct, SPI mode doesn't have an Inactive State. A failed ACMD41 is meant to keep responding in SPI mode.
Not to take this thread too far off track, I can 100% confirm, my hardware reset problem is due to the SD card. Maybe in the future, Edge cards could have some method to power cycle the card, such as dip switch setting to allow it's power to be tied to a pin, or something to that effect. I know there was discussion of this way back when and the consensus at the time was we didn't want to consume another pin to power cycle the card. I would settle for something that would allow the reset button to power cycle the card with the next iteration of the Edge. I think it may be needed.
Apologies if I'm off here because I currently have no interest in SD card stuff but isn't this issue covered here?
https://forums.parallax.com/discussion/174988/new-sd-mode-p2-accessory-board/p1
Yes, that one can power cycle its SD card.
However the SD card slot in this conversation is the 4-pin config, shared with the boot EPROM, built into many project/dev boards like the Edge and Eval boards. There is no SD power cycle pin on such boards.
Interesting ...
Been messing about with this boot problem again, using my P2 EDGE.
I have found that the P2 EDGE boots quite reliably from the SD Card if you ONLY unplug and replug the power cable. It boots fine on initial power up, and will also happily reboot if you press reset or toggle DTR.
Also, the P2 EDGE boots quite reliably from the SD Card if you ONLY unplug and replug the Prop Plug from the P2_EDGE and then use reset or DTR.
However, it generally fails to boot from the SD Card if you instead unplug and replug the Prop Plug from the PC. If you do that it generally won't boot using reset or DTR. What makes this confusing is that when it gets into this state, you can make it work correctly again by removing and re-inserting the SD Card. Then it will boot using reset or DTR.
Anyone have any idea what's going on here?
I use my "microDOS" - it boots from flash, then it opens the SD and can load and run a binary from it.
This configuration has no problem with a SD. I can reset a P2 using the button on the breakout board, connect the prop plug, etc, SD works OK, no hangups, sometimes (rare cases) it dosen't list the files after resetting but then normal reset with a button is sufficient.
The only problem was using the flash and SD at the same time - this topic: https://forums.parallax.com/discussion/175020/flash-and-microsd-in-the-same-program-how-to-flexprop#latest . Using a smartpin based, mode 0 based, flash access procedure disables the SD even if it is not mounted. The solution was to use mode 3 timings and bitbanging.
Ross,
Pik might be highlighting a good point. Inverting the SPI clock pin to idle high might help. Same with the MOSI pin, when unused, leave it set high.
The SD boot process is built into the P2 itself. Nothing I can do about it until I my program is executing, and of course if the Prop doesn't boot it never gets a chance. I will try booting it from FLASH instead, but if it is an SD card lockup then this may not actually solve the issue. Also, it will require a rewrite of the SD card plugin, so it might take me a while.
As @ke4pjw said, we need to be able to power cycle on-board peripherals like SD Cards. Future board designers please note!
I was meaning any post-boot SD accesses. And that also goes for any post-boot EEPROM accesses too, use SPI clock mode 3. That impacts the SD card as well.
For those that are experimenting with the P2 Eval board, we included an option to powercycle the SD card. You'd need to move one resistor, then you can toggle power with an IO pin.
Huh, I'd missed that. It's there as an option (via pin P57) in both RevB and RevC Eval boards:
A shame we don't have this option on the P2 EDGE. Next revision, maybe?
Some people may have spotted that I was talking complete nonsense here!
There is nothing to stop a program booting from FLASH and thereafter using only the SD Card. So I only need to rewrite my SD Card plugin if I want to use both the FLASH and the SD Card from within the same program (as @evanh's code does). But I don't currently need that capability.
So I just tried booting from FLASH instead of the SD Card, and it seems to work reliably - so far I have not had any failures either booting or subsequently accessing the SD Card, no matter how I plug and unplug things.
So while I still can't explain why booting from the SD Card sometimes fails, it seems there is a workaround - i.e. just boot exactly the same program from FLASH instead.
Ross.
Wonder if would have been possible to have hubset reset pull down the reset pin…
Try programming the fast boot stub into flash. It bypasses one of the SD boot checks (and makes the boot time non-painful, too!).
Not sure if it works from flash though, I've only tested it for SD boot. Also, change/remove the LED pin to taste.
CON _CLKFREQ = 300_000_000 DAT org 0 asmclk '' Patch pullup check wrlong #0,##$fc5b4 ' not sure why it fails but ok '' Move filename into place mov $1DC,name+0 mov $1DD,name+1 mov $1DE,name+2 drvh #38 ' Set LED call #$fc578 drvl #38 ' Clear LED if fail jmp #$ name byte "LOADTEST","BIX",0>
Thanks. Tried it.
It doesn't lock up the SD card, but it also doesn't actually boot the Propeller when executed from FLASH either. With this program in FLASH the Prop doesn't boot on a power cycle - you have to physically press the reset button. Also, thereafter you have to press the button twice to reboot again. I tried several different programs - some which use the SD and some which don't, but all get the same result. Odd.
Just booting your own program from FLASH seems to be the best answer. Still not had a failure using this method.
Yes using boot flash is much safer. Coming from a telco gear background I'd never choose something out in the field using a P2 to boot from SD, it just seems less reliable and results could also vary from card to card, sockets can be damaged, file systems corrupted etc. It's fine for playing with things on the bench where you can reset manually after problems but in the field use flash. Look at the problems people have with Raspi's and corrupted SD cards causing issues.
If you wanted to boot a new P2 test image from SD or use an SD card for doing a firmware upgrade for example, then just have a well tested SD bootloader present in (protected) flash where you have some control to at least try to recover if things go bad, or can flash an error LED, display a boot/upgrade failure message, etc. As I recall SD boot on the P2 was somewhat of a last minute feature and so didn't get much soak time to iron out all issues. There was a bit of a mad rush at the end creating the final boot ROM. Plus the sharing of pins with flash is another one of its complications and needs careful control to get it working correctly. Use flash.
I agree, don’t trust uSD boot enough to rely on it in field use. Maybe it’s ok, but don’t know enough to be sure…
I thought I had posted this video. It demonstrates the issue.
PS: You also cannot program the Flash on the P2 Edge when the SD card is mounted and have it boot. This is problematic. You can program the RAM and have it boot. I am unsure why.
Nice video. If you get the chance to respin your lighting controller board and have any spare P2 pins you might be able to put another (u)SD card connector on the lighting board (on different IO pins to boot FLASH) including a power down FET circuit under P2 control. Then your startup application can boot from FLASH and you'd be able to restart the SD card's power each boot and look for new config files or source HTML files etc. That's the long term path I'd probably want to take, though it obviously requires a respin which might be undesirable if you've already made up lots of these boards.