Known good/bad uSD card types?
RossH
Posts: 5,455
My 32Gb Sandisk Extreme uSD card recently died after years of hard service in my Propeller 2, so I bought a replacement. The shop did not have a SanDisk Extreme, but it had a SanDisk Ultra. I thought the only difference was the speed (which I didn't need) but not so 
The Propeller 2 boots from the Ultra when I hit the reset button, but it won't reboot using HUBSET. I have re-read all the old threads I can find about the various known uSD card issues, but I can't find anything especially helpful. I simply can't use this card.
This issue keeps coming back in various forms. I now keep my uSD cards in two separate piles - those that work reliably with the P2, and those that don't. Yes, I can find other uses for those cards, but perhaps we could keep a list somewhere of common uSD card types and whether or not they are compatible with the Propeller 2?
Ross.
EDIT: HUBSET, not HUBEXEC
Comments
What would hubexec have to do with it? I don't really understand what you're trying to say there.
The main card I use is a SanDisk Ultra 16GB, but an Extreme 64GB also works. However, such information is worthless, because these days honesty is dead and they'll just change out the internals of the same SKU without notice. And not to mention the many counterfeit cards in circulation.
I’m thinking any newer card should work? Might have to reformat as fat32 though and I think 32GB is the largest format that is recognized?
Found this on the expresif site:
What is the maximum size supported by FatFs?¶
Due to the limitations of the Windows system, FatFs is currently generally only available on storage devices up to 32 GB. Storage devices larger than 32 GB use other file systems, such as exFAT.
But, Windows will let you format at 128 GB as 32 GB, if you really want to use it.
My bad. I meant HUBSET, as in ....
HUBSET {#}D - Configure global circuit selected by MSBs %0000_xxxE_DDDD_DDMM_MMMM_MMMM_PPPP_CCSS Set clock generator mode %0001_xxxx_xxxx_xxxx_xxxx_xxxx_xxxx_xxxx Hard reset, reboots chip <--- THIS ONE! %0010_xxxx_xxxx_xxLW_DDDD_DDDD_DDDD_DDDD Set write-protect and debug enables %0100_xxxx_xxxx_xxxx_xxxx_xxxR_RLLT_TTTT Set filter R to length L and tap T %1DDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD_DDDD Seed Xoroshiro128** PRNG with DI will edit the top post.
So hitting reset button works, but soft-reset doesn't? That sounds strange. They should be the same. The main possible difference is timing, so maybe add a delay? (making sure all the pins are floating during this)
This is a completely arbitrary M$ bullshit thing, FAT32 supports drives up to 2TB.
On Windows, you can use this to create large FAT partitions: http://ridgecrop.co.uk/index.htm?guiformat.htm
I don't think it has to do with either formatting or FAT. I tried all the combinations I could think of, including the same combinations that work with other cards. I also tried using the SD Association official SD card format program instead of using Windows format. Also, the card works fine in other devices. Also, I can boot my P2 from the card if I power cycle it, and I can even boot from Flash and then use the card. But I cannot boot from the card if I use HUBSET.
Ross.
I have tried adding delays to my own code before rebooting, and also accessing the card just before re-booting to ensure it has not gone to sleep (which is apparently a "feature" of Sandisk cards) - but I cannot do anything about the P2 boot process, which is where the problem is.
Perhaps there is some "magic" mode I can put the uSD card in before attempting to reboot, but I don't know what it might be
Ross.
Does it work if you replace your hubset soft-reboot with an infinite loop and then hit reset exactly once? Sometimes it works after two distinct resets, because the first one fails but gets it back into the correct state.
Does it work if you don't access the card during your program? If yes, try emitting about 8 clock pulses before resetting. Sometimes they need that (while CS is high) to properly go idle.
The sleep mode is not a problem. Engages after about 10ms and just increases command latency after waking up. If you want to avoid sleep, never release CS. The SD protocol (unlike lots of SPI devices) doesn't require CS edges for framing, so you can just leave it low at all times.
In my experimenting with the various SD cards I have, which isn't a large number, I do have two Sandisk Extremes, one a 32GB, the a more recent 64GB. The other four or five cards are a collection of Kingston, Adata, Samsung and other lesser brands. Some are older than both the Sandisks, while others are new.
Well, the timing behaviours, particularly fetch time of the first block read, can differ a lot. And it's the Sandisk's that have the biggest fluctuations. The two cards are different to each other as well as the non-Sandisk cards. The other cards all seem to have similar responses as each other, like they're all using the same internal controller.
Just to be clear, there wasn't any bad or tricky behaviour. Just noted the Sandisks were the outliers is all. It points to Sandisk doing their own in-house controller while everyone else, including even Samsung, appear to be just licencing a generic controller block.
There is something about doing some fake reads when releasing uSD …. Just ran into that and maybe related? Maybe similar to clock pulses that @Wuerfel_21 just mentioned..
I’m thinking older cards don’t need this but new ones do?
Yes, do Ada's double-reset test. That should kick it with the extra SD clocks to prove this.
Yes, hitting reset - even just once - seems quite reliable. Also, the fact that I can boot from FLASH and then read from the card seems to lend some credence to evanh's idea that it is just a very slow first read after power up that is causing the boot problem, because I have longer timeouts in my code than the P2 boot code does.
Possibly this uSD card is just an "outlier", but I am not going to buy a bunch of potentially dud cards just to find out. However, perhaps Parallax might want to do so, so that they can offer a definitive list of card types that are known to work.
Ross.
Have a look at this thread from almost 5 years hither, regarding testing a wide variety of AU available 64GB sdxc cards and their individual needs with respect to additional clock pulses and/or P58 pullup
https://forums.parallax.com/discussion/comment/1465465/#Comment_1465465
In short, there were only a few cards that 'just worked' and the Sandisk Extreme was one of them, so you've been living a charmed life. For most other cards the thing to try in your program is to add those few extra clock pulses, typically just one or two is enough to release MISO. It makes sense to do this near the start of your program, so the SDXC is ready from that point on to be rebooted
Good information, and I will try it. But the real problem here is that the P2 uSD boot code does not simply "work" in all cases. If a successful soft re-boot depends on the user executing specific code before it will work, then that is an issue, and it needs to at least be fully documented. For instance, you don't know what other cogs may be doing, so you would also have to shut them down first. Perhaps Parallax could come up with a recommended soft reboot procedure?
With smaller (i.e. sub 64GB) uSD cards becoming harder and harder to source, I am hopeful that (at least in the short term) we can get a list of "known good" card types that the P2 is able to be reliably booted from (using HUBSET).
Ross.
Oh, Smile, I see, the SD card isn't detected because the SD card is holding the pins. Therefore no boot.
And the only reason that even a physical reset works is because that particular board design powers down the SD card when the reset button is pressed.
So, the solution is to ensure a board design that powers down the SD card when self rebooting.
Why would the size be an issue? Aside from being pre-formatted to exFAT, there's no difference between SDHC and SDXC. All marketing nonsense. Though I think there's a new standard for > 2TB cards coming out or something, lol.
And I believe power down is also the SD standard recommendation too. All boards should do it as part of the SD init sequence.
I think one also needs SD power control to switch between 4 bit and SPI mode, right? Hmm.
Other possible solution: just don't reset the chip. Nothing stops you from loading _BOOT_P2.BIX in your own code.
Cost. At my nearest shop, a 1 Terabyte Sandisk card is nearly $400. But a 32GB Sandisk card is under $10. And there are a couple of dozen different types and sizes in between those two extremes. And that's just Sandisk cards - they also sell Samsung. Which one should I buy? Especially given that even if I did decide I should shell out $400 I apparently can't be sure the card will work with the P2.
Once the power cycling is implemented at the board level, all cards should be okay.
Blurb from the Hardware Manual:
I wonder then about the crystal XO pin. It'll be stopped on each reset ... I guess there's no guarantee it'll be engaged at any point though.
I don’t seem to be having any uSD issues with my SimpleP2 boards. Not sure but maybe not sharing pins with flash chip helps ?
Also, was just at micro center and they have piles of small size uSD cards.
Not sure why …
Maybe they just overproduced at some point…
If everything is cleanly operated at runtime then it should be fine. Things like use of cmode 3 and always producing the extra clocks to complete each SD operation. Up-to-date Flexspin SD support does both of those, for example.
That then keeps the SD card in it's released state when not in active use. So then, upon reset, the boot sequence can correctly detect the SD as present and SD booting can start.
It the SD is not in released state then I'm guessing card detection upon reset will fail. So SD boot won't even be attempted.
You could try coding up a soft reset in the middle of a file read. You might find that fails a reboot.
Well I do have a slideshow app going where it reads bmp files from uSD.
Fsrw sometimes gives a -40 error on first mount attempt but works on second attempt . Not had it fail on reload yet. But I can test that some more and make sure to reload while it’s reading…
Just removed the waitms() in slideshow and reloaded ~10 times while was in middle of reading from uSD with no problems.
Doh! Sorry, since that board has no SD power down, all needed to do was hit the reset button. And that's a better test too since it actually has a chance of landing the reset in the middle of activity.
It just dawned on me that even an intentionally coded inline reset won't cause a problem because every command is terminated with excess clocks. Only if a SD command is still in mid-flight could the Flexspin routines be tripped up. You'd have to do it via a second cog that resets while the main cog is doing the block transfers.
In the absence of a hardware power down, a "safe" soft reboot procedure would have to involve shutting down all other cogs, then sending the uSD some clocks (how many, to be safe?) before executing the HUBSET. But even this is not 100% guaranteed (e.g. if the uSD card has gone into inactive state).
I think it makes sense to do the extra clocks really early in your program, that way you know other cogs aren't running, and haven't yet done a hubset (not that I'd expect that to conflict). Then the SDXC is ready for whatever happens next.
Just about all the SDXC cards I tested just needed 1 or 2 extra clock pulses.
Eight is considered enough.
My light controller project boots from SD and requires you send CMD "c" before stopping the SD card cog. Basically I do a dismount, remount, and stop the filesystem cog. Then it can soft reboot cleanly. I had to add this as a part of the "over the air" firmware upgrade process.
The steps that @Tubular talks about with sending extra clocks probably is the same thing I am doing.