Does Taqoz 2.8 work with 32GB card?
Christof Eb. Posts: 910
edited 2023-03-27 14:24 in Forth
for a long time I have been using a SanDisk 16GB Ultra SDHC I A1 card, which worked.
Now I tried a SanDisk 32GB Ultra SDHC UHS-I A1 card, and I cannot get it to work. As error message I get "Invalid Partition". Is this not possible or ist there a special procedure necessary formatting it?
Hi @"Christof Eb."
I use the same SD card in my P2 EVAL - it should work for you too. I would try formatting as described towards the end of the glossary . Other people have had that message and the correct formatting fixed it.
No problems with this same card at my end either. Worked out of the box without the need for formatting. I've had some problems with other (non SanDisk cards) but in all these instances TAQOZ card formatter fixed these issues.
Rather strange. Using the SD-Card-Formatter with Overwrite Format, I was now able to make another 16GB card usable and revive the former 16GB card. But those two 32GB cards, which I purchased at the same time, remain stubborn. Will now try a third of this bundle. Aaah, these things are so very time consuming....
Edit: Third card does not work too.
.sd --- CARD: SANDISK SD SD32G REV$85 #230883838 DATE:2022/12
Do you use 64kB per cluster? The SD card formatter does not have this option. I tried to use 64kB with the Windows formatter and with Taqoz FORMAT without success. Perhaps it is a good idea to discard this recommendation?
Ok @"Christof Eb." , Sorry the 32gb cards aren't working still. I haven't tried 64kb clusters. I will delete that advice from the glossary.
Might be an idea to store some files on the 32gb cards and see that data can be read, all from the PC. Just in case the SD cards are faulty.
TAQOZ# .sd --- CARD: SANDISK SD SC16G REV$80 #2093716449 DATE:2020/6
TAQOZ# .sd --- CARD: SANDISK SD SD32G REV$85 #3030188542 DATE:2022/12
▒BOOTING.... ERROR - INVALID PARTITION00us,389227us,389154us,389081us
I am wondering, if those Iwrite 200mA are too much for the Kiss board????
Good idea, to test on another computer. Yes 32 GB works there.
Here's the report from .DISK for my 32 Gbyte Sandisk SD card:-
So I notice that 'Iwrite Vmax' is 10mA not 200mA, whatever that means.
There is the possibility that at least your 32 Gbyte SD cards are fake of course - there are many such devices - see youtube. The fakes will report the size on the label, but fail when subject to a 'capacity test' program. They can be smaller capacity devices than advertised.
I tend to buy SD cards from a large computer shop just outside my home town to minimise the chance of buying a fake..
Thanks again! 128 sectors / 65KB Cluster works on 16GB.
32GB cards had been bought at and from Amazon. H2testw on PC reports OK, no errors.
I will try to get a better understanding of FILE.FTH as I need to read and write ( audio ) data files, which I had not done up to now....
Any further ideas on this? I have tried every SD on the bench <=32GB. invalid partition every time. P2 Edge w/ 32MBram. Tried various formats etc. very intermittent functioning.
Hi, since I switched back to 16GB, it works here. Did not yet investigate further.
I bought a Sandisk Ultra Plus 32gb SD card from Currys today - the smallest they sell now. (They are our local electronics chain store) Without formatting it, I plugged it into the P2-Eval and used BU to save the system onto the card. Taqoz booted up when the reset button was pressed. Here's what .DISK reported:-
I notice that Iwrite Vmax is 10mA, like my other 32Gb device.
I now tried one of the "bad" 32GB cards with APropOs, which means the filesystem of FlexProp and it works. I can read and write files onto it. So it seems to be a problem of Taqoz.
That doesn't surprise me, suspected that Taqoz pushed the SD card interface hard to give the highest data rates. Good to hear the cards can be used on the P2.
Yes, my direction of thought went also to speed. I have experimented:
00644 006 00000000 clkdly long 0 ' SPI clock waitx delay => to 8
00648 007 00000008 sddly long 8 ' sd clock delay => to 16
0064c 008 00020004 sdhl long $2_0004 => $40008
Additional capacitors 3v3 to GND at the connectors nearby.
All these things did not help.
!SD! .sd does give:
So !SD!, which does some sort of reset to the SD seems to help for a short while.
!SD! mount, does not work
At the moment I suspect, that perhaps the time between a SD command and data might be too short????
Any other ideas?
I don't have SD card expertise, so don't know what to suggest other than ...
It's probably not worth delving deeper into timing etc because the 'problem space' is quite large. I still believe your Amazon 32 Gbyte cards are fakes, albeit functional ones - they probably weren't made by Sandisk. In the attached spreadsheet, I've listed the output from .DISK for three of my 32gb Sandisk cards that work with Taqoz. You can see the parameters are very close to one another in all three parts, purchased over a two year period - and this set is different from your readout. Your part is quite a bit slower I think.
I would use your SD cards on your other devices (PCs, phones and tablets) and buy a genuine Sandisk card or two from somewhere trusted that you can return them too if they don't work out with Taqoz.
Thank You Bob for the overview!
Yes, I have ordered some new cards "SanDisk Extreme 32GB". I am relatively sure somehow, that these "bad" cards are no fakes. Think positive :-) . I could imagine, that SanDisk did some changes in late 2022, perhaps to reduce cost or because of parts availability, who knows. After all the cards work under other circumstances. There was and still is some "excitement" (I don't know, if this is the proper word for "Reiz" here.) for me to find and fix the problem in Taqoz.... Perhaps I will find a good description of the protocol and get some new ideas how to tackle it.
Puah, this drives me mad....
New bought at and from Amazon: SanDisk Extreme 32GB A1 V30.
Does only work shorttime after !SD!
Suppose all of your cards are OK. Let's assume the same for your KISS board and your Taqoz image. Maybe there is something with the combination of your KISS board and your Taqoz image that none of your cards like ?
What if I tried your Taqoz image with my KISS board and my 32 GB cards, both SanDisk nad non SanDisk ones ? That would either confirm or rule out the "combination effect", whatever that is. Do you think it to be a worthy experiment ?
thank you very much for the offer!
I have now copied the image to a SanDisk Extreme 32GB from 2018
TAQOZ# mount --- CARD: SANDISK SD SE32G REV$80 #3007066386 DATE:2018/3 ok
And this works.
So at the moment, such test seems only to be relevant, if you would have SanDisk cards from autumn 2022.
This has already stolen so much time from me and from Bob, so at the moment I don't think, that someone else should invest time here.
Edit: I should mention, that the bootloader (which is not Taqoz, but P2 ROM) can load the image _BOOT_P2.BIX from these "bad" cards.
If both flexspin VFS and the bootloader can access the cards, it would indeed seem that there is a problem with TAQOZ and its SD driver...
Not sure what whacky issue would allow it to correctly read the card ID registers but fail the actual sector reads. The TAQOZ code looks like line noise to me so idk what it's doing, but I'd hook up a logic analyzer and see what the patterns look like from TAQOZ vs flexspin.
I like that. Consider yourself lucky if that holds true only for the TAQOZ for you.
It's just the code, like any other if one knows how to go about it and it's very comapct and efficient.
Got some "new" result by chance. Something seems to be borderline. While the first 6 measurements of latency are "wrong", the last 2 measurements are reasonable.
As far as I think to have found out, the reading of the card registers is done by a completely independent lower speed code than high speed reading of a sector.
Can you suggest a "SD-card interface and timing guide for the very beginner"? I do not own a logic analyzer, but I have a 100MHz 4 channel oszi.
What do you think of this following code? For me, the clock generation is "obscure". It is done by the smartpin in parallel and independently from the shift-in.
Thank you Christof
Oh wow, what a terrible little routine. From just a quick glance (currently filling up a bath...):
sdhlvalues stay properly in sync?
To investigate 2., I'd suggest putting an FLTL and DRVL pair between the
.l0label and the WYPIN. Might need to play with
Also, yes, a storage oscilloscope should be sufficient to investigate SPI signals.
It's very verbose, but the ideal place to look up on the SD protocol is the official specification.
Getting access to it involves some messing around with account registration and email verification if I remember.
Fuck that noise, here it is: (with the copy-paste protection removed, too): https://mega.nz/file/7TBVhCiQ#xxrwLOhsIQZZQhlGUP33O5ptsGH1fT9sIQUtO_tPNbc
They inexplicably removed the timing sections in the public document, but SPI mode is really just SPI. We only care about SPI bus mode, disregard the rest of the document.
Thanks for your feedback about the routine, I will try to write some less smart slower code and to patch it into that place. SPISET is only used by this routine, so there should be enough space, I hope. There is already code there to shift in 32 bits. It should have it's advantages to use code, that I can understand....
Ok, it was not that smart routine. But it has something to do with start up of the SD-card. Timing or reset or whatever. The "solution" is idiotic. Instead of trying it twice ( Peters way ), we try it 10 times with a pause and do not use !SD but only !SD! .
On Peters P2D2 card there is a possibility to switch off and on the power supply to the SD card, which is used by !SD.
!MOUNTA seems to work with both of these "bad" card types:
Thanks for all the help! I did try to understand the startup procedure in "Physical_Layer_Simplified_Specification_Ver6.00", thank you, @Wuerfel_21 !
Oh wow, what a simple fix. Maybe there's a loop missing somewhere where it's supposed to wait for the card to go ready? Idk, if it works it works. I've actually never dealt with SD init, all the proper custom SD drivers I wrote assume that something else already initialized it into SPI mode.
Yes, I think, the status of initialization is not known well at this point, because Taqoz might be started by flash, or by the file in the SD bootsector or by the _BOOT_P2.BIX file. And the bus might be used by other devices so CS is probably off. Perhaps these cards fall into some sleep more quickly or their healthy sleep needs longer calling "Coffee is ready!" This !SD routine, called by the original !MOUNT, does switch off CS. Perhaps it is not so good to repeat that.
Some other -perhaps helpful- links for similar problems:
https://convict.lu/pdf/ProdManualSDCardv1.9.pdf says, that SanDisk cards will go to sleep after 5ms.