When running the sample from the SDK 2.2:
we get error for a number of different SD cards (we assume it is the card type that is not supported). Is there any plans for changing the drivers? The plan here was to use the fatfs and the fsl drivers for it. Seems it is currently not possible (unless customers are using the SD cards supported). We only needs very small amount of data stored, so 1GB cards would be more than sufficient. We saw the error on our own hardware originally (LPC54606) and moved to the LPCXpresso54608 board to verify.
Only change to the original sample is "USE_MKFS" is set to 0 and:
The cards tested and their returncode from f_mount():
(Please note that the 4GB card labelled "SanDisk" with SDHC also does not work)
I found this thread when searching for a solution to our micro SD-Card problem. On the OM13092 board, full size SD cards work fine, micro SDs in adapters don't. Initialization always fails/hangs. Anyway, I also found this, pointing me into the right direction:
https://github.com/trezor/trezor-firmware/issues/65
It seems that Micro-SD cards have internal pull-ups on Dat3 for Card-Detect, which must be disabled in order to use the Dat3 for data transfer. So I copyfied the SD_SetDataBusWidth() in fsl_sd.c to the following:
static status_t SD_ClearCardDetect(sd_card_t *card)
{
assert(card);
SDMMCHOST_TRANSFER content = {0};
SDMMCHOST_COMMAND command = {0};
status_t error = kStatus_Success;
if (kStatus_Success != SD_SendApplicationCmd(card, card->relativeAddress))
{
return kStatus_SDMMC_SendApplicationCommandFailed;
}
command.index = kSD_ApplicationSetClearCardDetect;
command.responseType = kCARD_ResponseTypeR1;
command.argument = 0; //disable card detect resistor
content.command = &command;
content.data = NULL;
error = card->host.transfer(card->host.base, &content);
if ((kStatus_Success != error) || ((command.response[0U]) & SDMMC_R1_ALL_ERROR_FLAG))
{
SDMMC_LOG("\r\nError: send ACMD42 failed with host error %d, response %x", error, command.response[0U]);
}
return error;
}
This should be called before switching from 1-bit to 4-bit-wide data bus. I hope this helps someone.
Side-note: Also, we have a custom board featuring a micro SD slot. Therefore we need to use the Dat3-pin for Card-Detect. This doesn't work on the OM13092 board, as there are hardwired pull-ups on the board for all the SD-Pins, which interfere with Dat3/CD.
Hello Carsten,
The MCUXpresso SD support does seem to be much less dependable than the LPCOpen code in my experience. Have you looked in the MCUXpresso SDK forum? There are several posts by JohnU that contain minor patches which I have found improved matters.
Best wishes,
Andy
Thanks Andy,
unfortunately, this does not come as a big surprise... I'm not exactly thrilled by the whole "MCUXpressos" SDK stuff, in my opinion (and many others) its a shame that LPCOpen was ditched....
I just had a look at the MCUXpresso forum, don't think I found anything from JohnU ? Do you perhaps have a link to some/one of his posts ?
Thanks,
Carsten
EDIT: Found it! https://community.nxp.com/thread/454708
Seems he and I are seeing the same stuff, I will read up on his posts, thanks Andy :smileyhappy:
See also sdmmc SD_Write()/SD_Read() failed with ATP card
"The issue concerns sdmmc library bug (I finally solved) in SD_Init() in the file sdmmc/src/fsl_sd.c:
SD_SelectBusTiming() calls SD_SwitchFunction() which sets block size to 64bytes (512bits).
Therefore SD_SetBlockSize(card, FSL_SDMMC_DEFAULT_BLOCK_SIZE) should be called again before SD_Init() exits."
best regards
J.
Thanks a lot John,
this seems to fix the problem for our old cards!
I just, as you recommended, added SD_SetBlockSize(card, FSL_SDMMC_DEFAULT_BLOCK_SIZE); just before the SD_init() function exits. :smileyhappy:
Glad you found the SD posts. I agree on MCUXpresso, it seems very rough in places with obvious holes in the provided functionality. Probably ok if all you want to do is build the demos in the MCUXpresso IDE but much less useful for real work in a custom environment. The number of issues being reported on these forums doesn't inspire confidence either...
Certainly not, I'm having a hard time convincing the right people here that the LPC546xx is the "right way to go" at the moment :smileysad: I really really hope that NXP/Freescale gets up to speed on this and show some progress, the LPC546xx family is way too nice for this lack of support.
Hi,
Please check the following bug warning SDIO Errata + SDRAM on LPCXPRESSO 54608 Notice
Have a great day,
Sol
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi
We are working on your question, just give us some time.
Regards
Vicente Gomez