https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/799403 E2E customer reported increased current consumption. Calling fopen() results in a continuous current draw of 18.5 mA where the prior observed current draw was 1.5 mA. This was replicated by apps and R&D. Debug Findings: The high current condition occurs after sending block read commands (CMD17,18). The multiblock read command (CMD18) is terminated by sending the stop command (CMD12). The SD spec requires CMD12 after CMD18 but not after CMD17. It is not explicit if CMD12 after CMD17 is incorrect. However it was seen that calling CMD12 resulted in the end of the high current condition. The current draw dropped back to 0.18 to 0.2 mA. The SD card responds with an illegal command bit set if CMD12 is sent after CMD17. No other error conditions are seen. Therefore it is recommended to change the read behavior of the SDSPI driver to always issue a CMD18 multiblock read and then a CMD12 stop. CMD17 will no longer be used by the SDSPI driver, which should prevent the high current condition. 6/3/19 Update - A post on a online community suggested that sending a 0xFF after de-asserting the CS line post read() would send the card to low power mode. This fixed worked for the one setup used to debug, even without the single/multi block read modification discussed above. Additionally it was found that the high current condition can also be triggered by a write operation. This was missed previously because a subsequent read operation (post-fix) will drop the current to normal levels. The high current condition after a write can be fixed by polling the SD card until it finishes the write, and then deasserting the CS line to finish the write. Presumably, de-asserting the card after the card accepted the new data but before it had finished writing the data causes the card to stay in a high power state. The customer reported normal current consumption after applying a fix for read() and write() operations.