Following the disaster of having the 4gb Kingston SD card stop responding, the focus of the week was to find a way to get the non-responsive SD cards to work on the PICTail. A lot of knowledge was gained about the SD cards initialization process (the process at which some of SD cards stop responding).
Debugging the MDD Initialization Stack from Microchip
Continuing on from the previous week, debugging was continued on the current Initialization process from Microchip. Following the failure to force the card to complete the initialization by bypassing the various processes where the card encounters errors, the next attempt was to try and find out why the card fails to respond correctly to the given commands. For doing so, the commands sent to the SD card were individually checked for the responses. The initial command to send the card to Idle State returns the correct response all the time, however, it was seen that at some times, several attempts were needed to be made to send the card to Idle State. For the crucial CMD8 where the SD card fails to initialize, the initialization code sends the command with an argument of 0x1AA, where the 1 represents the voltage range of 2.7 – 3.6V according to the SD Specifications Part 1 Physical Layer Simplified Specification [2013] and the AA represents the check pattern. The first modification made to check the functionality of the SD card response was by changing the check pattern and seeing if the SD card responds correctly. The response did change, but the card responded with an incorrect response. The next few attempts were made by changing the voltage range specification in the command argument and after some tweaking, a correct response was found from the SD card. Another modification made was by adding a while loop to retry the CMD8 until the correct the response is received as in some cases (especially for larger capacity cards) the command may need to be sent a few times before it respond correctly. However, not much success was yielded from this as in most of the debugging, it was found the the response does not change much.
In the cases where the SD card did respond correctly, the card either fails to read the CSD correctly or successfully completes the initialization process but fails to read the MBR of the SD card properly, same as the previous week. One more problem was that the SDHC card was continually being recognized as a SDSC card which is perhaps the main reason why the initialization process fails to read the CSD register. Further debugging was continued but the SD card was not successfully initialized. Following discussions with the supervisor, it was decided that a custom initialization stack was to be written to try and ensure that a wide range of SD cards work on the PICTail board.
Writing own Initialization stack
This was a particularly confusing and difficult task as I had no experience of writing my own stack from scratch before. A bit of research was needed to learn how to write a stack such as this and a lot of insight was also gained from the work done by one of the previous interns (https://blog.aeste.my/archives/1905). Using the hardware profile for the Development Board, a few simple functions were written. The first function written (after appropriate declarations and configurations) was a sdSPIInit function which initializes the SPI on the board. The second function written was the sdSPIWrite function which is used to write a byte of data to the SPI port. The next function written was the sdSendCmd function which takes in three arguments (CMD, Argument, CRC) and writes it to the SD card one byte at a time. This function utilizes the sdSPIWrite function to accomplish this. One more function written was the sdReadResp which reads a byte of data from the SPI port. Finally, the function to incorporate all these functions to work together was written called sdSendCmdResp which sends a specified command with the desired arguments and and records the response from the SD card to be analysed. Initial testing was done with only CMD0 (which sends the SD card to Idle State) to see if the SD card returns the correct response. It was unsuccessful as the SD card returned did not respond to the command send.
The coding was checked again and it was found that part of the problem was that the data written to the SPI port was written too fast. During the initialization process, the clock speed should be around 300kHz so that the SD card can properly initialize. This cannot be accomplished using the normal SPI configurations from the C18 SPI libraries on the PICDEM.net2 as the PIC18F97J60 has a clock speed of 25MHz and can only be scaled by a maximum of 64, which still leaves the clock speed to be more around 400kHz. To fix this, the bit-bang method used by the Micropchip stack was implemented which writes the data one byte at a time. Following the modification to the sdSPIWrite function, the SD card did respond but with a busy response rather than the Idle State response. Further modifications are hoped to yield better results.
0 Comments