Elm-ChaN's tech notes on interfacing with SD card is fantastic. There are, however, some things left unsaid. Today, my colleague Thejasvi and I discovered two aspects not explicit in that tutorial.
1. The way /CS signal should be handled.
Before sending a command, make /CS low. Get the response, data packets ( if any ). Now, it is essential to make /CS high before sending the next command.
2. After one command is complete. That is to say, a command is sent and a response is got (mostly R1 response) , do NOT make /CS high. The card will go out of sync and wont accept new commands properly. After the R1 response is got, send atleast one dummy byte(0xFF) and then make /CS high. Now it is ready to accept new commands. This is probably because the card is completely inactive if no data is transmitted to it as no clock signal goes to it. My conjecture is that it needs a few clocks to resynchronize after a command-response before it can accept a new command. Thus the dummy byte after the R1 response.
1. The way /CS signal should be handled.
Before sending a command, make /CS low. Get the response, data packets ( if any ). Now, it is essential to make /CS high before sending the next command.
2. After one command is complete. That is to say, a command is sent and a response is got (mostly R1 response) , do NOT make /CS high. The card will go out of sync and wont accept new commands properly. After the R1 response is got, send atleast one dummy byte(0xFF) and then make /CS high. Now it is ready to accept new commands. This is probably because the card is completely inactive if no data is transmitted to it as no clock signal goes to it. My conjecture is that it needs a few clocks to resynchronize after a command-response before it can accept a new command. Thus the dummy byte after the R1 response.
No comments:
Post a Comment