Sandisk Ultra SD cards can fail to boot

[ghollingworth]

Description

After extensive debugging it seems that reads from a Sandisk Ultra can be corrupted if a read multiple command is received too soon after a previous stop transmission command. This is a bug in the Sandisk Ultra controller although we've not yet been able to pin down what is happening.

Explanation

During boot time there is a very small bit of code 'bootcode.bin' which sends commands to the SD controller very quickly... it seems that if we do long sequences of 4 block READ_MULTIPLE_BLOCK commands and then skip to elsewhere on the SDcard it will fail the next read.

So doing the following:

Send command: READ_MULTIPLE_BLOCK sector N
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Send command: STOP_TRANSMISSION
Send command: READ_MULTIPLE_BLOCK sector N+4
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Send command: STOP_TRANSMISSION
Send command: READ_MULTIPLE_BLOCK sector N+8
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Read data sector (512 bytes)
Send command: STOP_TRANSMISSION
Send command: READ_MULTIPLE_BLOCK sector K
Read data sector (512 bytes)
Send command: STOP_TRANSMISSION

So in the situation above we're reading lots of data from sector N though to N+11 then we skip to sector K where K is smaller than N (i.e. we are trying to read the second sector of the FAT)

Instead of reading the FAT it reads and returns sector N+12

Effect

The effect of this bug was diagnosed when it was seen with NOOBS v1.3, mostly because the files just happened to put themselves into the exact configuration that then triggered the bug! It was a matter of just copying and pasting the file elsewhere on the disk and it would suddenly work fine again!

Another possible effect of this bug is to fail booting after doing an rpi-update because the rpi-update will re-write the start.elf and it is therefore possible for the FAT partition to end up configured in this state!

Solution

I'm still awaiting confirmation from Sandisk that this is a known problem and that the workaround I've currently implemented is valid, it turns out that a simple workaround is just to send a SEND_STATUS command between the STOP and subsequent READ_MULTIPLE_BLOCK. This seems to be enough delay to make sure the SD card doesn't output the wrong data.

This has been fixed in NOOBS v1.3.2 and is awaiting testing before being pushed to raspberrypi/firmware

[sdcardtest]

So is the issue occurring on all the ultra cards and value of N is fixed or random value of N and K is causing the issue.

[ghollingworth]

I've got a reply from Sandisk who very generously pointed out the exact paragraph of the specification that we were violating with our bootcode!

The problem is there is a minimum time (of about 8 SD clock cycles) between commands and in bootcode.bin we were actually breaking this with the bootcode (no other code is fast enough to do this!)

So the fix we've got is suitable

[popcornmix]

I believe this is fixed now.