P2 SD Testing

Cluso99 · 2018-05-27 00:10

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.

jmg · 2018-05-27 00:29

Cluso99 wrote: »

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.

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.

Peter Jakacki · 2018-05-27 00:47

Why can't you abort the SD sequence the moment the CMD0 sequence fails? The CMD0 returns with a response of 1 and even if you allowed multiple retries that will still proceed through and ultimately fail initialization very quickly. The only command that takes a while to respond is the ACMD41 but this is only after the CMD0 CMD8 sequence, and on either you should be able to abort quickly. I guess the difference here is that I don't actually use timeouts for these two commands, just retry loops. A pullup resistor alone will never return with a response of 1 will it?

Tubular · 2018-05-27 01:29

Out of interest does the P60 pin neighbor VCC or GND? If it neighbors VCC what would be the maximum resistance that would effect a pullup? (With respect to not fully cleaned pcbs etc)

jmg · 2018-05-27 01:37

Tubular wrote: »

Out of interest does the P60 pin neighbor VCC or GND? If it neighbors VCC what would be the maximum resistance that would effect a pullup? (With respect to not fully cleaned pcbs etc)

The code shows a ~ 5us time, so that means values above 500k~1M should be ignored.
Noisy environments could pose a problem ?

Dave Hein · 2018-05-27 01:39

I agree with jmg. Provide a location where the user can specify the clock frequency.

Cluso99 · 2018-05-27 03:20

I had thought of providing a register to set the timeout. I already do this for read data hub address, sector, length for reading a file, serial hub buffer for rx/rxstring/monitor, baud, and a few others can actually be overridden too.

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.

Peter Jakacki · 2018-05-27 03:33

$FF is not actually a response, it is a lack of response. That is why my CMD0 loops several times looking for a response and fails the initialization if it doesn't get it. Works perfectly well for me.

cgracey · 2018-05-27 03:57

Dave Hein wrote: »

I agree with jmg. Provide a location where the user can specify the clock frequency.

Yep.

Peter Jakacki · 2018-05-27 04:15

If we specify a clock frequency then we need to lock it into SD or Flash and then if we lock it into SD then SD needs a simple CMD0 retry counter anyway.

Cluso99 · 2018-05-27 04:16

OK, got it.

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.

"> "                            ' set autobaud
<Ctl-D>                         ' goto the monitor
1DF- xxxxxxxx <cr>              ' set 32-bit timeout value of 1s for the current clock
Gfc558<cr>                      ' call SD routine to boot from SD card

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

jmg · 2018-05-27 05:01

Cluso99 wrote: »

OK, got it.

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.

The above looks good.
What is the command sequence to AutoBaud + Change SysCLK(enable PLL) + AutoBaud again + Set32b_1sec timeout ?

Peter Jakacki · 2018-05-27 10:49

I still don't understand why you cannot test for a valid response (not $FF) rather than an non-response ($FF)?

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)

: INIT BEGIN 0 0 CMD DUP .BYTE SPACE 1 = UNTIL ;

Here are 3 different cards but all the others just came back immediately with a valid response.

TAQOZ# INIT 3F C1 01  ok
TAQOZ# INIT 01  ok
TAQOZ# INIT 01  ok

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:

2787 cycles = 34.837us

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.

Cluso99 · 2018-05-27 13:15

I have traces of some 30+ SD cards.many provided on the forum by users who tested my code a few years ago. There are a number of cards that respond with $FF (or are late to respond) where a few FFs are received before the $01 (or $00 in the case of the Dane card). Some of those cards were SanDisk.

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

SD testing v111a
SD card type: 3 = SDHC/SD V2(block)  (passed)
4404: CS1 CLK0 ;
4408: CS1 CLK0  0 00000040 00000000 00000095 000000FF (1) 00000001 ;
4430: CS1 CLK0  8 00000048 000001AA 00000087 000000FF (1) 00000001 000001AA ;
445C: CS1 CLK0 55 00000077 00000000 00000087 000000FF (1) 00000001 ;
4484: CS0 CLK0 41 00000069 40000000 00000087 000000FF (1) 00000000 (1887) (11805016 clocks) 147ms ;
44BC: CS1 CLK0 58 0000007A 00000000 00000087 000000FF (1) 00000000 C0FF8000 ;
44E8: CS1 CLK0 16 00000050 00000200 00000087 000000FF (1) 00000000 ;
4510: CS1 CLK0  9 00000049 00000000 00000087 000000FF (2) 00000000 000000FF (1) 000000FE ;
4548:      (16 bytes) CRC: 0000008C 00000004 ;
4558: CS1 CLK0 10 0000004A 00000000 00000087 000000FF (2) 00000000 000000FF (1) 000000FE ;
4590:      (16 bytes) CRC: 0000001F 000000BA ;
45A0: CS1 CLK0 17 00000051 00000000 00000087 000000FF (2) 00000000 000000FF (2758) 000000FE ;
45D8:     (512 bytes) CRC: 0000002B 000000B1 ;
45E8: CS1 CLK0 17 00000051 00000001 00000087 000000FF (2) 00000000 000000FF (330) 000000FE ;
4620:     (512 bytes) CRC: 00000000 00000000 ;
4630: <eof>      (13442692 clocks) 168ms
CSD register...
0000: 40 0E 00 32 5B 59 00 00 1D 8A 7F 80 0A 40 40 B9  @..2[Y.......@@.
CID register...
0000: 03 53 44 53 55 30 34 47 80 A1 3D D0 99 00 C6 7F  .SDSU04G..=.....
MBR/VBR sector 0 ...
Valid MBR

and a SanDisk 32GB card

SD testing v111a
SD card type: 3 = SDHC/SD V2(block)  (passed)
4404: CS1 CLK0 ;
4408: CS1 CLK0  0 00000040 00000000 00000095 000000FF (1) 00000001 ;
4430: CS1 CLK0  8 00000048 000001AA 00000087 000000FF (1) 00000001 000001AA ;
445C: CS1 CLK0 55 00000077 00000000 00000087 000000FF (1) 00000001 ;
4484: CS0 CLK0 41 00000069 40000000 00000087 000000FF (1) 00000000 (1887) (11805016 clocks) 147ms ;
44BC: CS1 CLK0 58 0000007A 00000000 00000087 000000FF (1) 00000000 C0FF8000 ;
44E8: CS1 CLK0 16 00000050 00000200 00000087 000000FF (1) 00000000 ;
4510: CS1 CLK0  9 00000049 00000000 00000087 000000FF (2) 00000000 000000FF (1) 000000FE ;
4548:      (16 bytes) CRC: 0000008C 00000004 ;
4558: CS1 CLK0 10 0000004A 00000000 00000087 000000FF (2) 00000000 000000FF (1) 000000FE ;
4590:      (16 bytes) CRC: 0000001F 000000BA ;
45A0: CS1 CLK0 17 00000051 00000000 00000087 000000FF (2) 00000000 000000FF (2758) 000000FE ;
45D8:     (512 bytes) CRC: 0000002B 000000B1 ;
45E8: CS1 CLK0 17 00000051 00000001 00000087 000000FF (2) 00000000 000000FF (330) 000000FE ;
4620:     (512 bytes) CRC: 00000000 00000000 ;
4630: <eof>      (13442692 clocks) 168ms
CSD register...
0000: 40 0E 00 32 5B 59 00 00 1D 8A 7F 80 0A 40 40 B9  @..2[Y.......@@.
CID register...
0000: 03 53 44 53 55 30 34 47 80 A1 3D D0 99 00 C6 7F  .SDSU04G..=.....
MBR/VBR sector 0 ...

Peter Jakacki · 2018-05-27 13:27

Tests are always skewed by the tester. If your tester has a bug either in code or in criteria, the tests will be skewed. Nonetheless, with or without $FF's, the solution is far far simpler than a long long timeout. I don't want to see a long timeout in my booting, even if the correct frequency is set, it is still too long. I've have all kinds of cards I have tested and tested. One thing my CMD routine always does is issue eight dummy clocks before attempting a command otherwise things can get skewed.
A long timeout is totally avoidable.

Peter Jakacki · 2018-05-27 15:03

Here are my tests with lots of different cards, some old, some new, some 4G, some 64G.
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.

CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  .SDSU32G 432A_2B70 NO NAME    32k 30,432M    623377 cycles = 7.792ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  .SDSU32G 432A_2B70 NO NAME    32k 30,432M    3010113 cycles = 37.626ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
MOUNTING CARD  .SDSS16G F16B_22ED TACHYON    32k 15,189M    2828545 cycles = 35.356ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  'PHSD32G 690B_541A TAQOZ      32k 30,168M    4935225 cycles = 61.690ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  'PHSD32G 690B_541A TAQOZ      32k 30,168M    2428137 cycles = 30.351ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  'PHSD32G 690B_541A TAQOZ      32k 30,168M    2406145 cycles = 30.76ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  .SDSU08G 3437_3130 NO NAME    32k 7,576M    2790993 cycles = 34.887ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  ...SDC   2F1E_66F1 IOT5500    4k 3,932M    5958481 cycles = 74.481ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  ...SDC   2F1E_66F1 IOT5500    4k 3,932M    5914497 cycles = 73.931ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  .SDSL16G 6131_6232 NO NAME    32k 15,189M    2781017 cycles = 34.762ms 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
MOUNTING CARD  .SM00000 F184_E94B WIDGET     4k 3,758M    339737 cycles = 4.246ms 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
MOUNTING CARD  .SM00000 F184_E94B WIDGET     4k 3,758M    339729 cycles = 4.246ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  ...NCard 2E0E_36DA NO NAME    32k 7,655M    6324681 cycles = 79.58ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
MOUNTING CARD  ...NCard 2E0E_36DA NO NAME    32k 7,655M    6324681 cycles = 79.58ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD  .SDSL08G 2545_ADF1 TAQOZ      32k 7,576M    2830449 cycles = 35.380ms 
CHECKING CARD CMD0     663507 cycles = 8.293ms              
MOUNTING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    7770249 cycles = 97.128ms 
CHECKING CARD CMD0     19641171 cycles = 245.514ms          
MOUNTING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    336953 cycles = 4.211ms 
CHECKING CARD CMD0     67852659 cycles = 311.287ms          
MOUNTING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    336953 cycles = 4.211ms  ok

TAQOZ# $FF HUBSET �^  ok

CHECKING CARD CMD0     18075516 cycles = 225.943ms 
MOUNTING CARD      12470457 cycles = 155.880ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    31237009 cycles = 390.462ms |
CHECKING CARD CMD0     333196 cycles = 4.164ms 
MOUNTING CARD  .SDSL08G 6338_3533 NO NAME    32k 7,576M    2562473 cycles = 32.30ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  ...NCard 2E0E_36DA NO NAME    32k 7,655M    6350553 cycles = 79.381ms \
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD  .SM00000 F184_E94B WIDGET     4k 3,758M    322017 cycles = 4.25ms \
CHECKING CARD CMD0     333196 cycles = 4.164ms 
MOUNTING CARD  .SDSU08G 3437_3130 NO NAME    32k 7,576M    2772601 cycles = 34.657ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSU08G 3437_3130 NO NAME    32k 7,576M    2772601 cycles = 34.657ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD  .SDSL16G 6131_6232 NO NAME    32k 15,189M    2761585 cycles = 34.519ms -
CHECKING CARD CMD0     333196 cycles = 4.164ms 
MOUNTING CARD  .SDSU32G 432A_2B70 NO NAME    32k 30,432M    2990817 cycles = 37.385ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSU32G 432A_2B70 NO NAME    32k 30,432M    2990489 cycles = 37.381ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD32G 3248_DC0D NO NAME    32k 30,168M    1989833 cycles = 24.872ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSU04G 3434_6461 NO NAME    32k 3,777M    2080121 cycles = 26.1ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD  .SDSU04G 3863_3738 WIDGET2    32k 3,777M    2170337 cycles = 27.129ms \
CHECKING CARD CMD0     663476 cycles = 8.293ms 
MOUNTING CARD  ...NCard 0012_D687 NO NAME    32k 7,654M    8219585 cycles = 102.744ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  ...NCard 0012_D687 NO NAME    32k 7,654M    8219585 cycles = 102.744ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  sBGNCard E443_6D2C NO NAME    32k 7,646M    7534737 cycles = 94.184ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  ...NCard 8391_23A1 DAWN       32k 7,655M    7076001 cycles = 88.450ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  ...SDC   2F1E_66F1 IOT5500    4k 3,932M    6028953 cycles = 75.361ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD32G 690B_541A TAQOZ      32k 30,168M    2408897 cycles = 30.111ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD  .SDSU32G 32FE_D582 BOOT       32k 30,432M    3008969 cycles = 37.612ms \
CHECKING CARD CMD0     333196 cycles = 4.164ms 
MOUNTING CARD  .SDSL08G 6130_6430 NO NAME    32k 7,576M    2623657 cycles = 32.795ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSL08G 6338_6430 WIDGET     32k 7,576M    2872129 cycles = 35.901ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSD04G 74C0_22AC  V       ^ 64k 3,780M    2583905 cycles = 32.298ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSU04G 3264_3565 NO NAME    32k 3,777M    2166681 cycles = 27.83ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    8303057 cycles = 103.788ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD  ...SDC   F84E_1690 NO NAME    32k 3,929M    8457001 cycles = 105.712ms \
CHECKING CARD CMD0     333196 cycles = 4.164ms 
MOUNTING CARD  .SDSL08G 2545_ADF1 TAQOZ      32k 7,576M    2812017 cycles = 35.150ms -
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSL08G 2545_ADF1 TAQOZ      32k 7,576M    2812017 cycles = 35.150ms \
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  .SDSL08G 5E5F_7F14 TAQOZ      32k 7,576M    2811689 cycles = 35.146ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 0000_0000   xH       0k 0M    4665321 cycles = 58.316ms |
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 0000_0000   xH       0k 0M    1498473 cycles = 18.730ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 0000_0000   xH       0k 0M    1498473 cycles = 18.730ms |

( REFORMAT 64G TO FAT32 )
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 8192_C438 FAT32      32k 59,648M    4542353 cycles = 56.779ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 8192_C438 FAT32      32k 59,648M    1595425 cycles = 19.942ms /
CHECKING CARD CMD0     2916 cycles = 36.450us 
MOUNTING CARD  'PHSD64G 8192_C438 FAT32      32k 59,648M    1595425 cycles = 19.942ms -

jmg · 2018-05-27 19:39

Peter Jakacki wrote: »

....
Every time I insert a card it times the CMD0 operation which is typically 37us but that is dependent upon the SPI bus speed. ..

CHECKING CARD CMD0     2931 cycles = 36.637us 
..
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
CHECKING CARD CMD0     333219 cycles = 4.165ms 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     2931 cycles = 36.637us 
CHECKING CARD CMD0     663507 cycles = 8.293ms              
CHECKING CARD CMD0     19641171 cycles = 245.514ms          
CHECKING CARD CMD0     67852659 cycles = 311.287ms          

CHECKING CARD CMD0     18075516 cycles = 225.943ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     663476 cycles = 8.293ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     333196 cycles = 4.164ms 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us 
CHECKING CARD CMD0     2916 cycles = 36.450us

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 ?

Peter Jakacki · 2018-05-27 22:17

@jmg - except for one old card which didn't seem to work properly (=faulty) most of these are fine but I'm redoing my SDCHECK routine to print out the details on one line a little clearer along with min/avg/max etc. Given that one card was extremely slow to respond is more of an indication of failure perhaps but mind you, I wasn't doing any kind of clocking before CMD0, only waiting 100ms after card insertion and then CMD0. I will find out more about this card but I have a great many cards and different cards I can check fortunately.

Peter Jakacki · 2018-05-27 23:17

I think we are hampered by lack of testing, or more correctly, lack of testers. We need ones who have an A9 board to be able to load the V32d image which allows a ROM file to be loaded after power-up and thereafter all hard resets use the new "ROM". If we want to test another ROM we cycle the power and load it in again. Is anyone other than Chip and Cluso and myself doing this? I have a 32k TAQOZ boot image on SD card that I'm having some boot issues with on various cards, sometimes it boots, sometimes it doesn't.

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.

Cold start
----------------------------------------------------------------
  Parallax P2  .:.:--TAQOZ--:.:.  V1.0--141          180528-0130
----------------------------------------------------------------
TAQOZ#

Peter Jakacki · 2018-05-28 01:53

I've cleaned up the reset switch and put in some extra ground rails on my breakout board as well as soldering my SD card directly since I had pin headers and jumper cables before for testing.

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?

Peter Jakacki · 2018-05-28 04:17

While I investigate further as to why SD boot is taking so long perhaps this might explain why the Cluso's SD boot code is taking a long time seeing a 01 response to a CMD0. It looks like chip select is left low and never goes high and low again to resynchronize the SPI packet so it never sees a valid command until eventually it happens to drift into the correct pattern for the command and crc (active during CMD0 and CMD8). Maybe I'm wrong but I did a CMD0 from TAQOZ at the same time to double check and immediately gets a 01 response to say it's ready. Ignore the RESET/RXD/TXD signals as they aren't connected but pickup crosstalk.

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.

Peter Jakacki · 2018-05-28 04:28

Update - Now that I have removed the finger trouble, it seems the SD booter is going from an invalid response on CMD0 straight to CMD8 rather than retrying for a good response of 01. That's not right though.

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?

cgracey · 2018-05-28 06:31

Peter, could you Skype me?

P2 SD Testing

Comments