I continued working on the task with the SD cards. I first tested out the read and write example code in Microchip’s manual on Implementing File I/O Functions Using Microchip’s Memory Disk Drive File System Library (AN1045). The code can be found on page 10 on the manual.

The files that I included in the MPLAB project are FSconfig.h, FSIO.h, HardwareProfile.h, salloc.h, SD-SPI.h, Makefile, 18f97j60_g.lkr, FSIO.c, salloc.c, SD-SPI.c and also writeReadDemo.c which is the example code that I gotten from the Microchip’s manual mentioned above.

Upon the first try on running the code, I ran into a problem where all the functions mentioned in AN1045 manual could not be used. I had included the header files and the source files for the functions but it still did not work. So I looked into the linker file, which is the 18f97j60_g.lkr. By referring to page 14 of the AN1045 manual, which the Appendix A: The PIC18 Linker Script. I made the appropriate changes to 18f97j60_g.lkr by reserving three blocks of memory: _SRAM_ALLOC_HEAP, dataBuffer and FATBuffer. The size and address of the three sections are same with the one in the manual. After the change in linker file, all the functions included in the AN1045 manual can be used.

There are three SD cards to be tested with the task, specifically a 1 GB microSD card, a 4 GB SDHC card and a 4 GB microSDHC card. I try to run my sample code on the microSD card and the SDHC card. The result is that nothing happened with both of the cards but both of the cards can operate perfectly well with a computer. By inserting various LEDs indicator in the code, I found that both of the cards did not made it past the line FSInit().

I added various configuration bits, additional lines to try to make both of the SD cards work. The configuration bits I set can be seen in this line:


I added few lines to set the I/O pins to digital, set the pins as input and output appropriately and add an extra function to test whether the PIC18F97J60 detects the SD cards during the test run. The codes can be seen as below:

// clear the LEDs for debugging
TRISJ = 1;
PORTJ = 0;

// set i/o pins to digital
ADCON1 = 0xF;

// setting pins
TRISBbits.TRISB3 = 0;
TRISBbits.TRISB4 = 1;
TRISAbits.TRISA4 = 1;

TRISCbits.TRISC3 = 0;
TRISCbits.TRISC4 = 1;
TRISCbits.TRISC5 = 0;

//To detect the presence of SD card
while (!MDD_MediaDetect())
{ PORTJ = 0xFF; };

But after making these changes, both of the cards did not operate with the PIC18F97J60 but the PIC18 was able to detect their presences. So, I decided to test out with the last card, which is the microSDHC card. Surprisingly, it turns out the microSDHC card was able to operate well with the PIC18, able to create, read, write and delete files in the card. I reported these findings to my supervisor, and he told me to try to format the two SD cards which is not working with the PIC18. So I wrote a simple test code by using the FSformat() function to try to format the SD cards, it turns out that both of the cards were not able to be formatted by the PIC18.

I inserted various LED indicators in the source code to pinpoint which command line which the SD cards failed. It turns out that the microSD card failed at the line where the PIC will be expecting a data start token (0xFE) after sending the READ_MULTI_BLOCK command. But, the card responsed with 0xFC which is neither indicating it is busy (0xFF) nor an error happened (0b0000XXXX, where XXXX indicates the type of error happened).

The SDHC failed in a much earlier stage where the PIC sent a CMD8 to the SDHC card. Since it is a SDHC card, the card should response correctly to the CMD8 command from the PIC18, but it did not. There is a comment in the source code where if the card responses correctly to CMD8:

//If we get to here, the device supported the CMD8 command and didn’t complain about our host
//voltage range.
//Most likely this means it is either a v2.0 spec standard or high capacity SD card (SDHC)

I did some searching in the internet about voltage issue and I found few forums discussing on this issue. Where it turns out they did some changes to the board’s hardware and change the voltage from 5V to 3.3V. Details on these can be read in the two following links to the Microchip forum.

Again, I reported my findings to my supervisor and he asked me whether I can reformat the working microSDHC card and asked me look into the SD card physical spec to understand more about the unexpected behavior of the two not-working SD cards. In the end, I was able to reformat the microSDHC card without any problem and I did not find anything in the SD card physical spec detailing why the microSD card responses with 0xFC when a data start token is expected for the READ_MULTI_BLOCK command. And the 0xFC is actually a data start token for the WRITE_MULTI_BLOCK command which I did not send.

I again reported my findings to my supervisor, and he suggested that I work with the working microSDHC card in the meantime while try to learn as much as possible before proceeding to my next task on TCP/IP. By the way, I found that the CMD8 command is actually sending 0x1AA to the card and expecting 0x1AA from the SDHC card, which the card did not response correctly. The 0xFC and 0xFE for the microSD is actually only a one bit error. I am thinking that it might be related to the voltage issue but I could not think of any test to confirm my hypothesis.

1 Comment

Yeoh Zijie · 2013-07-12 at 19:11


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.