P2 SD Testing
Cluso99
Posts: 18,069
in Propeller 2
Dilema...
SD is booting fine on the P2.
However, in order for the SD routines to work not only at the RC speed which is ~30MHz max, but to also work with user code that may be running up to ~200MHz max for us overclockers if we can get away with it. To satisfy this, the timeout of 1s needs to be calculated for the fastest speed (200MHz). This gives around 10s timeout at 20MHz (the current testing FPGA RC speed). Under normal circumstances, this is an SD card issue, and nothing we do will speed up the card.
But the problem lies if there is a pull-up on P60 (the CSn pin of the SD card) but no card. Chip revealed this during testing of the pullups recently. We decided to pass at that point. The SD card is providing the internal pullup - we are recommending using the SD's internal pull-up for circuitry, so why would there be a pullup present without an SD card. Well, it's possible the SD card has failed. How possible? I don't know.
So, if an SD card is present, but it is failing to respond to the initialisation sequence, the 1s timeout at the fastest speed will give around 7s at the RC Boot speed of the P2. This means that before the serial can take over upon an SD boot failure, around 7s may have elapsed. Note that this is a faulty SD hardware problem. Easy solution is to remove or replace the SD card and the problem is solved. Note if the boot sectors or boot files are not found, the SD boot code will return as fast as the SD responds which is usually ~25-100ms.
While the final ROM window remains open, I would like to try a few solutions. BUT, I need as many of you as possible to test as many SD cards as you can, just to ensure I don't break something.
So, what is your best hardware to do this?
a) P2 - Again I can give you the source to recompile. But what FPGA boards and FPGA code? I am presuming the full P2 version 32a/b. A couple of the early v32 and prior have the SD cards mapped to P58-62 and these should work fine for this testing. The test rom code we are testing with is only available for 123 A9 and BeMicroCV-A9 boards.
b) P1 - I can give you source to recompile to any pins and xtal
I am not even certain I will have the time to do this, but perhaps its worth a try.
SD is booting fine on the P2.
However, in order for the SD routines to work not only at the RC speed which is ~30MHz max, but to also work with user code that may be running up to ~200MHz max for us overclockers if we can get away with it. To satisfy this, the timeout of 1s needs to be calculated for the fastest speed (200MHz). This gives around 10s timeout at 20MHz (the current testing FPGA RC speed). Under normal circumstances, this is an SD card issue, and nothing we do will speed up the card.
But the problem lies if there is a pull-up on P60 (the CSn pin of the SD card) but no card. Chip revealed this during testing of the pullups recently. We decided to pass at that point. The SD card is providing the internal pullup - we are recommending using the SD's internal pull-up for circuitry, so why would there be a pullup present without an SD card. Well, it's possible the SD card has failed. How possible? I don't know.
So, if an SD card is present, but it is failing to respond to the initialisation sequence, the 1s timeout at the fastest speed will give around 7s at the RC Boot speed of the P2. This means that before the serial can take over upon an SD boot failure, around 7s may have elapsed. Note that this is a faulty SD hardware problem. Easy solution is to remove or replace the SD card and the problem is solved. Note if the boot sectors or boot files are not found, the SD boot code will return as fast as the SD responds which is usually ~25-100ms.
While the final ROM window remains open, I would like to try a few solutions. BUT, I need as many of you as possible to test as many SD cards as you can, just to ensure I don't break something.
So, what is your best hardware to do this?
a) P2 - Again I can give you the source to recompile. But what FPGA boards and FPGA code? I am presuming the full P2 version 32a/b. A couple of the early v32 and prior have the SD cards mapped to P58-62 and these should work fine for this testing. The test rom code we are testing with is only available for 123 A9 and BeMicroCV-A9 boards.
b) P1 - I can give you source to recompile to any pins and xtal
I am not even certain I will have the time to do this, but perhaps its worth a try.
Comments
The booter will only ever run on the RC Clock, but if you want to allow users to call the ROM code at any SysCLK speed, why not have a defined location that sets the clock speed for timing ?
You already will be defining the entry points for the routines, so one that sets SysCLK is easy to manage ?
The booter could check the config registers, but that does not tell it the crystal frequency, so a user call that can change the default value seems the simplest and most flexible ?
If you have a routine like SysClks_per_10ms, that defaults to 200000 for 20MHz.
The code shows a ~ 5us time, so that means values above 500k~1M should be ignored.
Noisy environments could pose a problem ?
But, it's not that simple to provide a register to set because...
1. No spare registers ATM - I use a nice even 32 already.
2. No spare code space. Yes, it's only a few more longs. But Peter is on the scrounge
Now, why can't I abort on CMD0? Well, the response of $FF is legitimate, and if that is seen, then the code needs to look further for a response. How many $FF's are legitimate on a CMD0? I don't know as the spec does not say. Sorry Peter, even SanDisk cards reply with $FF to any of the commands!!! And I have seen other responses as well, some of which are obviously invalid. But a retry of the command fixes the problem. It seems the card must be missing some clocks as it does not respond quickly enough, and it gets out of sync. It is an SD requirement that $FF is a stall code, not a retransmit code! The normal use of the $FF is for delaying the read/write of a sector/registers once the CMD17, CMD24, and a few others, which is then followed by an $FE to indicate the send/receive block is now ready to proceed.
Now it's also a requirement that CMD0 has a retry count suggested to be 10. Just another counter that is required. But you cannot retry the CMD0 if you receive an $FF reply. It not in the spec and from what I have seen it does not work reliably, if at all.
And one last thing. This code has been squashed to a minimum, so the routines are general purpose. It's not so easy to modify the lowest level, and not be sure you don't break something at a higher level.
Peter, just the pullup resistor responds with $FF. But how many is legitimate and how many is not? And how do you pass this information to the low level without using any more code and any more registers?
So, that was my purpose to get some more testing results to confirm if I could get away with not conforming to the spec, and shorten the timeout.
Yep.
Here is how you boot without the 10s timeout in the case your SD card is dead, or you incorrectly designed your hardware and put a pullup on P60.
I needed an extra register for this, so I now require cog registers $1BF-$1DF for the SD booting. Not quite as neat as $1C0-$1DF
The above looks good.
What is the command sequence to AutoBaud + Change SysCLK(enable PLL) + AutoBaud again + Set32b_1sec timeout ?
No matter what card I plug into TAQOZ, if I do a 0 0 CMD I almost invariably get a 01 response first time after inserting into a running system. One comes back with $3F $C1 before 01, but just that card
Using this quick check (the crc reverts to $95) Here are 3 different cards but all the others just came back immediately with a valid response. Not one card ever came back with $FF which is actually just the master SPI reading an empty slave SPI register that hasn't yet been written. This is the same reason we can clock in $FF to a card without problems.
btw - timing this from the very first CMD0 until a positive response: This is coded for 80MHz timing but still it is under 150us so a simple retry counter is all that is needed but almost invariably the response is immediate.
So no, I am not going to ignore the FF because I have seen it. We have to cater for what is out there. This is the ROM Boot code, so it has to cater for as many cases as possible.
Here is a SanDisk 4GB card trace and a SanDisk 32GB card
A long timeout is totally avoidable.
Every time I insert a card it times the CMD0 operation which is typically 37us but that is dependent upon the SPI bus speed. The second line times not only the card initialization that is required but also mounting it as FAT32. The internal serial number and ID is printed including the optional name when the card is mounted.
Why the large variation here, up to 311ms ? - but most common is 2916, or 2031 cycles
Did you try the equivalent of a cold-power-up test ? IIRC, some SD cards have a boot procedure themselves, so the first power-up is slower than all others.
Does that CMD0 always test for 01 return value - Could Cluso try the same tests on his cards ?
I have a reset switch which I use and it may be a bit noisy so I will look at making it a clean signal next and then checking boot. I've attached my TAQOZ.BIN which I rename to a _P2_BOOT.BIX or BIY or course. This image starts up at 115200 baud 80MHz with an earlier version of TAQOZ that can run in 32k RAM, so it starts immediately with the splash and prompt.
What worries me now is why does the SD booter take as long as it does? It seems to be busy clocking the SD for 700ms which is way over the top and way too slow for a 32k image. I'm going to grab all this on an analyzer but the boot routines need improving. This is with the latest SD booter code. A random sector read takes less than 2ms at 20MHz in TAQOZ and timing my SD init routines from a cold start shows this is actually taking 120ms. So 128+120+ say another 22ms should be around 270ms although an SD multiple sector read is much faster than that.
I changed to 80MHz in TAQOZ and freshly initialized a card (removed and inserted) and it still took 120ms, so this init code is not introducing any extra unnecessary timeouts, it's mainly the ACM41 where the card takes its time to clean up and respond.
Isn't anybody actually testing and measuring real world SD booting?
You can't see my chip select going low from high but it's there, whereas I can't ever see the SD boot code do it. But then again, it might be finger trouble as I check further.....something to ponder.
EDIT - looks like the chip select was on the RESET trace - so I will get put it back and get the LA to resynch to it.
That $48 on the right of the capture is the CMD8.
I've reconfigured the LA since it was clocking on the falling edge but I will continue to look. But as you can see, the 01 response is immediate. I'm panicking because there hasn't been enough testing done at this level and I've been busy and still busy with TAQOZ. Can anyone help?