I tried to use the multiple block write command on a SAME70 to write to an sdcard using HSMCI and SDIO. To write a single block (512Bytes) works well but has a high jitter in the response time of the card. I searched the internet and found on several places the hint to write contingous blocks and also use the command (CMD25) for multiple blocks write.
To get contingous blocks I used the FATfs f_expand() function. That seems to work well. However I couldn't get the CMD25 to work. My base is the ASF3 library. In this library a multi block write is transformed to a loop of single block writes. So this isn't really what I need. I'm new to the HSMCI and sdcard topic and therefore I did some basic investigations. During this I found the following define in the above mentioned file:
#define SDMMC_CMD25_WRITE_MULTIPLE_BLOCK (25 | SDMMC_CMD_R1 | SDMMC_CMD_WRITE | SDMMC_CMD_MULTI_BLOCK)
If you decomposite the different defines you come to a value of:
This value is written to the HSMCI_CMDR register. However, this value will do the following settings:
Command Number (CMDNB): 25 (fine for me)
Response Type (RSPTYP): 0 (unclear to me because the define seems to want it to set to 48Bit response)
Special Command (SPCMD): 1 (unclear to me because this will issue a INIT command and I'm not sure if this is the case for CMD25)
OpenDrain Command (OPDCMD): 0 (fine for me)
Max Latency for Command Response (MAXLAT): 1 (fine for me - I guess this is related to the internal error management that will wait now 64 cycles)
Bit 15 is undefined in the HSMCI_CMDR but set to 1 - in the above mentioned file this is commented as the 'write direction bit' that is bit 18 instead
Transfer Command (TRCMD): 0 (unclear to me because it defines a 'NO_DATA' transfer, but maybe covered by the CMD25 itself)
Transfer Direction (TRDIR): 0 (fine for me - it is defining a write transfer direction)
Transfer Type (TRTYP): 2 (unclear to me because this will define a MMC Stream - and I want to have a SD Card multiple block (defined by the value 1))
three more fields that are all set to 0 and don't seem to be of interest.
If I compare it with a single block write (that seems to work reliable) the main difference is the TRTYP field that is set to 1 in this case. This 1 signals a 'multiple block'. Again, this sounds wrong to me but maybe covered with the block count in the corresponding DMA transfer.
- Can anyone comment to my list above and let me know if I'm wrong or right?
- Does anyone run the multiple read/write block commands for a sdcard using the HSMCI with SDIO on a SAME/V/S device and can let me know how it has been implemented?
Thanks in advance