RTOS/CC2642R: High Current Consumption Following f_open Call (FATFS).

Hey TER,

Thanks for your response. I'm pretty confident that f_open is a required call for the FATfs. Additionally, the code I provided was written by a TI Forum member and can be found at in the following post:

I'm also a little confused since in the link you provided you state that f_open should be used instead of fopen:

I tried fopen and it did reduce current consumption by 10mA, but I was unable to get data to write to the SD card despite the fopen returning correctly. I am not too surprised by this result since all documentation from  Elm-chan and discussions from a number of my previous TI E2E posts indicated that f_open should be used.

http://elm-chan.org/fsw/ff/doc/open.html

As for getting the code to work on your device, try adding the following switch statement:

case FR_NO_FILESYSTEM:
          fr = f_mkfs("", FM_ANY, 0, workarea, sizeof(workarea));
          fr = f_open(&fsrc, "myfile", FA_CREATE_NEW | FA_WRITE);
          System_printf("fr after f_open: %d \n",fr);System_flush();
          break;

The code I provided works on my CC2642R1 LaunchPad device so you might also want to verify your pin configuration to your SD card booster pack. Here's a pic you can use for verification:

  If you still encounter issues you might want to refer to the TI written code in the link I provided, provided here again for your convenience:  This code was provided just as a reference, please feel free to use any working code you may have that will allow you to successfully call f_open() within the FATfs API.

 When you get writes to the SD card working could you please measure the current consumption to the SD card?

Thanks,

- Stephen Poanessa

Do you have the project you used for the CC2640 testing? I want to run this with my setup to see if it gives lower current in my case before sending a ticket over to R&D. 

Th driver team reproduced the issue and looked at the spec some more and it looks like it's a bug in SDSPI. They suggest to try this code block:

    assertCS(hwAttrs);

    if (sendCmd(object->spiHandle, CMD18, sector) == 0) {

        do {

            if (!recvDataBlock(object->spiHandle, buf, SD_SECTOR_SIZE)) {

                break;

            }

            buf = (void *) (((uint32_t) buf) + SD_SECTOR_SIZE);

        } while (--sectorCount);

        /*

         * STOP_TRANSMISSION - order is important; always want to send

         * stop signal

         */

        if (sendCmd(object->spiHandle, CMD12, 0) == 0 && sectorCount == 0) {

            status = SD_STATUS_SUCCESS;

        }

    }

    deassertCS(hwAttrs);

Please let me know if you manage to use the code/ get the current consumption down. 

Hello TER,

Thanks for your response.  I noticed that the code block provided in your last response is already present in SDSPI.c's SDSPI_read() function shown below.

That being said I'm not sure where this new code block needs to be inserted.  Could you please post a full copy of SDSPI.c with the fix included? 

I did attempt to run the device with the if(sectorCount ==1) statement removed, leaving only the if(sendCmd(object->spiHandle, CMD18, sector) == 0) statement and I witnessed no change in the device's current consumption.

I would also like to understand the root cause of the high current and how the provided code block addresses it.  Could you confirm that this change has been verified to resolve the high current issue on a CC2642R1 launchpad?

    assertCS(hwAttrs);

    /* Single block read */
    if (sectorCount == 1) {
        if ((sendCmd(object->spiHandle, CMD17, sector) == 0) &&
            recvDataBlock(object->spiHandle, buf, SD_SECTOR_SIZE)) {
            status = SD_STATUS_SUCCESS;
        }
    }
    /* Multiple block read */
    else {
        if (sendCmd(object->spiHandle, CMD18, sector) == 0) {
            do {
                if (!recvDataBlock(object->spiHandle, buf, SD_SECTOR_SIZE)) {
                    break;
                }
                buf = (void *) (((uint32_t) buf) + SD_SECTOR_SIZE);
            } while (--sectorCount);

            /*
             * STOP_TRANSMISSION - order is important; always want to send
             * stop signal
             */
            if (sendCmd(object->spiHandle, CMD12, 0) == 0 && sectorCount == 0) {
                status = SD_STATUS_SUCCESS;
            }
        }
    }

    deassertCS(hwAttrs);

Hi Stephen,

Yes, I believe you put the code block in the correct place: SDSPI_read(). The idea is to always do a multi-block read (CMD18) instead of a single block read (CMD17). CMD18 involves clocking the SD card for any number of blocks, until you send CMD12 to stop the multi-block read.

Let me talk you through the debug process I went through. I was able to replicate the high current consumption you experience after calling fopen(). I traced this down to a CMD17 that occurred as part of fopen, after which the current draw jumped to 18 mA and stayed there. I noticed that this high current condition also occur if sending a CMD18 instead, but stops after sending CMD12. It turns out you can also send CMD12 after a CMD17 to stop the high current but you get an 'illegal' command response. So the idea was to change SDSPI to always do a multi-block read so that we always sent a CMD12 that would end the high current condition. That was the plan anyways.

Did you place the modified SDSPI.c file in a folder (/ti/drivers/sd/) in your CCS project?

In this local SPSDI, if you could put a breakpoint before and after the sendCmd(...CMD18) I'm interested if you can see the high current start when you send CMD18 and end when you send CMD12. It is possible that this was specific to the SD card controller in my SD card, which would be unfortunate.

Another thing which worked for me, was to send 0xFF after the CS is deasserted. This worked without changing the CMD17/CMD18 logic as stated above. Change the end of the SDSPI_read function to look like this:

    deassertCS(hwAttrs);

    // Send FF with high CS to go low power
    uint8_t ffByte = 0xFF;
    spiTransfer(object->spiHandle, NULL, &ffByte, 1);

    SemaphoreP_post(object->lockSem);

    return (status);

Thanks,

Sean

Hey Sean,

Thank you so much for your response. To answer your first question: yes, the SDSPI.c had been removed from the drivers folder and has been imported directly to the project. This was done originally to allow a change in the SPI rate to occur.

Here are the results from the breakpoint test you requested:

Line 439: 5.16 mA

Line 441: 15.15 mA

Line 451: 15.18 mA

Line 452: 5.17 mA

With these breakpoints removed and the program running no decrease in overall current consumption was noted. For reference our code running on our boards with the CC2640 consumed between 1-2mA, compared to our new CC2642R1 boards, which consume between 16-20mA.

It seems as if somehow the newer code doesn’t let the SD card go into low-power mode. Are there other places in the code that differ between the codebases that would result in the higher SDcard currents? 

Thanks,

- Stephen Poanessa

Stephen,

Thanks for running that test. I'm guessing you got those current figures from your custom hardware and so those figures are total system draw? What is your idle current draw before f_open()?

Did you have time to try the extra 0xFF after the end of the read that I mentioned at the end of my last post?

I tried all the previous versions of the SDSPI driver but the same high current condition exists.

I've found that SDSPI_write also causes a high current condition. I didn't see it before because if SDSPI_read is called after SDSPI_write, then the current goes back down to sub 1mA. I was able to stop the high current condition after write() by waiting for the SD card to become ready again after the write operation. Now my SDSPI read/write functions look like this:

/*
 *  ======== SDSPI_read ========
 */
int_fast16_t SDSPI_read(SD_Handle handle, void *buf, int_fast32_t sector,
    uint_fast32_t sectorCount)
{
    int_fast16_t         status = SD_STATUS_ERROR;
    SDSPI_Object        *object = handle->object;
    SDSPI_HWAttrs const *hwAttrs = handle->hwAttrs;

    if (sectorCount == 0) {
        return (SD_STATUS_ERROR);
    }

    SemaphoreP_pend(object->lockSem, SemaphoreP_WAIT_FOREVER);

    /*
     * On a SDSC card, the sector address is a byte address on the SD Card
     * On a SDHC card, the sector addressing is via sector blocks
     */
    if (object->cardType != SD_SDHC) {
        /* Convert to byte address */
        sector *= SD_SECTOR_SIZE;
    }

    assertCS(hwAttrs);

    /* Single block read */
    if (sectorCount == 1) {
        if ((sendCmd(object->spiHandle, CMD17, sector) == 0) &&
            recvDataBlock(object->spiHandle, buf, SD_SECTOR_SIZE)) {
            status = SD_STATUS_SUCCESS;
        }
    }
    /* Multiple block read */
    else {
        if (sendCmd(object->spiHandle, CMD18, sector) == 0) {
            do {
                if (!recvDataBlock(object->spiHandle, buf, SD_SECTOR_SIZE)) {
                    break;
                }
                buf = (void *) (((uint32_t) buf) + SD_SECTOR_SIZE);
            } while (--sectorCount);

            /*
             * STOP_TRANSMISSION - order is important; always want to send
             * stop signal
             */
            if (sendCmd(object->spiHandle, CMD12, 0) == 0 && sectorCount == 0) {
                status = SD_STATUS_SUCCESS;
            }
        }
    }

    deassertCS(hwAttrs);

    // Send FF with high CS to go low power
    uint8_t ffByte = 0xFF;
    spiTransfer(object->spiHandle, NULL, &ffByte, 1);

    SemaphoreP_post(object->lockSem);

    return (status);
}

/*
 *  ======== SDSPI_write ========
 */
int_fast16_t SDSPI_write(SD_Handle handle, const void *buf,
    int_fast32_t sector, uint_fast32_t sectorCount)
{
    int_fast16_t        status = SD_STATUS_SUCCESS;
    SDSPI_Object        *object = handle->object;
    SDSPI_HWAttrs const *hwAttrs = handle->hwAttrs;

    if (sectorCount == 0) {
        return (SD_STATUS_ERROR);
    }

    SemaphoreP_pend(object->lockSem, SemaphoreP_WAIT_FOREVER);

    /*
     * On a SDSC card, the sector address is a byte address on the SD Card
     * On a SDHC card, the sector addressing is via sector blocks
     */
    if (object->cardType != SD_SDHC) {
        /* Convert to byte address if needed */
        sector *= SD_SECTOR_SIZE;
    }

    assertCS(hwAttrs);

    /* Single block write */
    if (sectorCount == 1) {
        if ((sendCmd(object->spiHandle, CMD24, sector) == 0) &&
            transmitDataBlock(object->spiHandle, (void *) buf, SD_SECTOR_SIZE,
                START_BLOCK_TOKEN)) {
            sectorCount = 0;
        }
    }
    /* Multiple block write */
    else {
        if ((object->cardType == SD_SDSC) || (object->cardType == SD_SDHC)) {
            if (sendCmd(object->spiHandle, CMD55, 0) != 0) {
                status = SD_STATUS_ERROR;
            }

            /* ACMD23 */
            if ((status == SD_STATUS_SUCCESS) &&
                (sendCmd(object->spiHandle, CMD23, sectorCount) != 0)) {
                status = SD_STATUS_ERROR;
            }
        }

        /* WRITE_MULTIPLE_BLOCK command */
        if ((status == SD_STATUS_SUCCESS) &&
            (sendCmd(object->spiHandle, CMD25, sector) == 0)) {
            do {
                if (!transmitDataBlock(object->spiHandle, (void *) buf,
                    SD_SECTOR_SIZE, START_MULTIBLOCK_TOKEN)) {
                    break;
                }
                buf = (void *) (((uint32_t) buf) + SD_SECTOR_SIZE);
            } while (--sectorCount);

            /* STOP_TRAN token */
            if (!transmitDataBlock(object->spiHandle, NULL, 0,
                STOP_MULTIBLOCK_TOKEN)) {
                sectorCount = 1;
            }
        }
    }

    /* Wait until the SD card is done programming */
    waitUntilReady(object->spiHandle);

    deassertCS(hwAttrs);

    SemaphoreP_post(object->lockSem);

    return ((sectorCount) ? SD_STATUS_ERROR : SD_STATUS_SUCCESS);
}

Notice the extra spiTransfer() at the end of SDSPI_read(), and the waitUntilReady() at the end of SDSPI_write(). Hopefully with both read/write tweaked, you will see your total system consumption go down. Let me know how that goes!

Thanks,

Sean

Stephen,

Glad to be of assistance! Thank you for reporting this issue. I filed a ticket to get this fix into our development branch so hopefully it will be incorporated into the next release.

Thanks,

Sean