Week #12 – SD Cmds

I tested out the code I had already written and found out that the power up sequence was not working as expected. After consulting with my supervisor he advised me to enable pull-up resistors in port B and test the input and outputs for the each pin. By setting the INTCON2bits.NOT_RBPU to 0, I was able to enable the pull up resistors. I then set my port B as output and checked to see the voltage across the pins when set to high and when set to low. There were no unexpected results, moreover after setting port B as an input and setting the port to high, I found that pins 4-7 behaved differently. At this point the PICDEM2.NET was tested using a UART to debug port B using a resistor. From the results it was established that port B was working fine and all physical connections were working.

I ran my codes again and I was still not able to proceed with power_on at that time I checked the software SPI library that MPLAB was using for compiling and found that it was the unmodified initial one. The compiler was confused since both include directories had the file with the same name. Hence I renamed the file and added it to the compiler. At this point I also added a delay in between the clock pulses and after compilation I found that my power_on sequence was successful.

I then moved on to the mode_select function and tested it out, the function was at a halt after sending CMD0, I modified my code to show the lower bits of output R1 which was 0x0F showing that the card was in idle state although erase reset, illegal command, and command CRC error was also set. At this point I checked the CRC for command 0 from the SD documentation and from another sample code obtained from the Internet and I found that my CRC was right. I then changed my code to input a real value; a value other than 0x00 when obtaining the R1 response and somehow this time I was able to get the card in idle state and proceed to the next command. I then was able to get the card’s voltage range and check pattern and hence proceeded to the function card_init. When I ran this function there were hitches and I found that the card I had was an extended / high capacity card.

I faced no problems during that part of testing and hence I proceeded to writing a function for reading and writing. At first I wanted to perform writing and therefore wrote a function “sd_write”. In order to write to the card the host has to send CMD 24 (WRITE_BLOCK), with the address as the argument, wait for R1 response, check if there were no errors and then send the start token and the data to the card. During this time the Chip Select (CS) is set to low. When the data is received the card responds with a data_response token and gives busy signal while write is in progress.

The card writes data in blocks and the sd_write function has 5 inputs; 4 bytes of write start address and the data. Initially I wanted to write just one byte hence the input data was also one byte. The function then sends out CMD24, checks R1 response and is R1 is 0x00 the start token which is 0xFE is sent along with data and a dummy CRC. I then checked the response token. There are 3 response tokens 0x05 for data accepted, 0x0B for CRC error and 0x0D for write error. When the function was tested out I kept getting errors and then my supervisor suggested trying to read from the card first.

The card was then plugged into a PC to test if there was any data on it. When plugged back into the board and the initialization was run I kept getting errors at the initialization stage. I didn’t know what was happening and therefore went back to the documentation. I found that after power up sequence I had to send CMD0 , check for response send CMD8 and check for response to identify the version of the card. There are 2 versions of the card each having a specific initialization sequence and I had not taken that into consideration.

Hence I modified my codes to follow the sequence shown in the figures 1-3 below. I also changed my function prototypes to have a separate function for each command. These functions return a value according to the response received, and the details for outputs are shown in Table 3 below.

After running all the function prototypes I was getting the result that the card enters idle state, is a version 1 card and error when sending CMD08. I then obtained byte 5 of R7 response and output it to the UART to check out the flags and found that the last 4 bits (bit 0-3) is set high, indicating errors in erase reset, illegal command and CRC. I have not yet been able to figure out what the problem is.

Figure 1: Sequence of commands to determine version of card

Figure 2: Version 1 card Initialization sequence

Figure 2: Version 2 Card Initialization Sequence.

Table1: PIN connections from the SD card to PIC18F97J60

Table 2: Command Index, Arguments and Responses

Table 3: Function Prototypes Input/Output and Description