This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TM4C1294NCPDT: SD Card Board Connection

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello Everyone!

I have a launch pad I am attempting to implement FatFS with and SD Card Breakout Board from robotshop.  I have been using the example fatsd from the resource library to no avail!  I'm thinking my issue is a wiring problem not necessarily a coding problem.  I will attach some photos of how I have this set up.  The error I'm getting is at this part of the code:

    //This is from the main project file
    SDSPI_Params_init(&sdspiParams);
    sdspiHandle = SDSPI_open(Board_SDSPI0, DRIVE_NUM, &sdspiParams);
    if (sdspiHandle == NULL) {
        System_abort("Error starting the SD card\n");
    }
    else {
        System_printf("Drive %u is mounted\n", DRIVE_NUM);
    }
    /* Try to open the source file */
    //Next line is where I'm having my problems.
    src = fopen(inputfile, "r");
    if (!src) {
        System_printf("Creating a new file \"%s\"...", inputfile);

This will result in the error:

 ti.sysbios.family.arm.m3.Hwi: line 1095: E_hardFault: FORCED
ti.sysbios.family.arm.m3.Hwi: line 1172: E_busFault: IMPRECISERR: Delayed Bus Fault, exact addr unknown, address: e000ed38
Exception occurred in background thread at PC = 0x00003dee.
Core 0: Exception occurred in ThreadType_Task.
Task name: {unknown-instance-name}, handle: 0x20003b98.
Task stack base: 0x20000360.
Task stack size: 0x1000.
R0 = 0x000000f9  R8  = 0x00009f59
R1 = 0x000001f3  R9  = 0x00000001
R2 = 0x00000002  R10 = 0xffffffff
R3 = 0x00007cc5  R11 = 0xffffffff
R4 = 0x00000000  R12 = 0x00000000
R5 = 0x20004334  SP(R13) = 0x200012a8
R6 = 0x00000002  LR(R14) = 0x00005c8f
R7 = 0x20004280  PC(R15) = 0x00003dee
PSR = 0x21002800
ICSR = 0x00423803
MMFSR = 0x00
BFSR = 0x04
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x0000000a
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
because I removed all system_abort lines in the code to try to diagnose why this is not working.

  • Would you please provide a list of which signals from the EK-TM4C129XL are connected to each of G, DO, CLK, DI, CS and + ? It is difficult to count pins and flip between the pictures.
  • Sure thing Bob,

    G Red Wire connected to Ground Pin
    DO Purple Wire connected to pin PD0
    CLK White Wire connected to pin PD3
    DI Black Wire connected to pin PD1
    CS Green Wire connected to pin PC7
    + Yellow Wire connected to 3.3V
  • Also, it seems that my DI and DO pins from the manufacturer are flipped. When I reverse those two pins I get an error if I include a disk_initialize(0);, it returns 0x01. When they are in their current position, it returns 0x00.
  • Sorry guys!

        src = fopen(inputfile, "r");
        if (!src) {
            System_printf("Creating a new file \"%s\"...", inputfile);
    
            /* Open file for both reading and writing */
            src = fopen(inputfile, "w+");
            if (!src) {
                System_printf("Error: \"%s\" could not be created.\n"
                              "Please check the Getting Started Guide "
                              "if additional jumpers are necessary.\n",
                              inputfile);
    //            System_abort("Aborting...\n");
            }
            //This is actually where the program crashes!
            fwrite(textarray, 1, strlen(textarray), src);
            fflush(src);
    

  • Hi Stephen,
    I checked your wiring configuration against the TIRTOS FatFS example and everything looks correct. I also consulted another (better) expert who confirms that the SD card need not be preformatted.

    Is it this card with the 3v/5v switch?
    www.robotshop.com/.../micro-sd-card-breakout-module.html
  • I told Bob incorrect information! It does not format the SD card.
  • Yes, this is the board that I'm using. I know there is a null pointer somewhere in the code for fopen, but I don't remember exactly where. I'll step through the code and post what variable ends up being null.

    Thanks Bob.
  • I have made sure the SD card I put in there is formatted to FatFS32.
  • I don't know if this helps at all:

    When declaring the const char inputfile[] = "fat:0:input.txt"; and const char outputfile[] = "fat:0:output.txt"; if I change the value to "input.txt" and "output.txt" the code runs smoothly, just doesn't actually write the file to my sd card. Also, once I've done this one time, it will change from creating the file to using existing file.
  • Also running it without an SD card in this configuration the code still works.
  • Disclaimer: I am "less than qualified" in this area's (ok - many area's) regard.     (yet cash register rings loudly - and w/adequate frequency...)

    Most always - test across "multiple" such boards (or devices ... other SD Cards in this instance) proves of use/value.     May we assume that you've, "Test/Verified" this particular SD Card (via other means) - and that it has performed?

    Firm/I have past noted that, "Newer, higher capacity SD Cards" - may not "fare well" when used w/such small MCUs (those found "here" and from (other) ARM MCU vendors - this is NO "knock" upon this vendor.)

    Might your use of a lower capacity SD Card be tried - and results reported?

  • Great points cb1_mobile.

    I have not tested this board in any other capacity other than through the launchpad. I have a secondary sd board coming, but that doesn't necessarily give the information you're looking for.

    I am currently using a 4 gb sdhc card. I will see if we have a lower capacity card and see if that does the trick.
  • Thank you - appreciated.

    Too often - those w/"focused expertise" neglect and/or discount the value of, (KISS Directed/Inspired) broader-based, "fact-finding!"

    The "difficulty or challenge" - enforced by "higher capacity" (even type) SD cards - has been recognized/reported - and I believed to warrant (some) mention here...

    (as a "kid" I had (tested/proven) "photographic memory" (not so much now) yet IIRC - "HC" cards DO (or past HAD) challenged!)

  • I tried a 2 gb SD card and that was able to write.  It is still having an issue that I'm going to look further into where when it's trying to read the file back in I get this error:

    Invalid CIO command (0) in the CIO buffer at address (0x20003948) was not recognized. Please check the device and program memory maps.

    This is happening I'm guessing at this block of code because the error keeps being written until I end the program:

        while (true) {
            /* Read from output file */
            bytesRead = fread(cpy_buff, 1, CPY_BUFF_SIZE, dst);
            if (bytesRead == 0) {
                break; /* Error or EOF */
            }
            cpy_buff[bytesRead] = '\0';
            /* Write output */
            System_printf("%s", cpy_buff);
            System_flush();
        }

  • Thanks again - great to see "such responsiveness" here. And it (does) appear you are "gaining ground" - due to the "KISS" (make NO assumptions) method! (Pity that KISS is banned here...of course - minus ANY explanation/justification!)

    I've added to my initial post - should memory serve "HC" cards (increase) the "degree of difficulty."
  • Here's a fun one. We got a 32 GB SDHC I and that works in the system. I think I'm having an ejection problem though because it stripped it's formatting.
  • As always - "when in doubt" - expand the "size of the sample."     (Pure KISS)

    Thank you for your "Resolution" award - appreciated.

    I would still, "Search for more (i.e. several) lower capacity, most basic, "SD cards" procure & test "those."    (i.e. yet even more, KISS)

    Should those "work" - you then are (reasonably) well-armed to discover, "Where & When (maybe even Why) the more advanced SD Cards FAIL" - and potentially develop a, "Real Solution."