SD Card only works when debugging?

[william_lyons]

I have software that uses the SD card/MMC drivers from NXP to communicate with an SD card.

• If I boot the software while a debug session is running, and then issue the command (over the serial port) to initialize the card and read a block, everything works fine.
• If I power cycle the board (which breaks the debug connection), the driver hangs after the serial command is issued.
• If I then connect a debugger using the "attach" option and look, the CPU is stuck in the following code snippet

                  do

                {

                     error = USDHC_TransferNonBlocking(base, &s_usdhc1Handle, &dmaConfig, content);

                  } while (error == kStatus_USDHC_BusyTransferring);

                  which is lines 267-270 of SDMMCHOST1_TransferFunction() in sdmmc\port\fsl_sdmmc_host.c

• If I then use the debugger to restart the software and run, it can read the card fine.
• If I start a new debug session - including flashing code down to the chip - and then immediately terminate the session before releasing the CPU from reset, the software boots, and I can read the card without hanging.

What is the debugger doing that doesn't happen during non-debug execution?  How do I fix/get around this?

I've tried dumping various hardware registers to try to see differences between the two cases, but nothing obvious stands out.

I'm using an MIMXRT1052 on a custom carrier board.

-Will

[tom_pope]

Hi Will,

Did you ever solve this issue?  I'm experiencing the exact same problem with an eMMC device connected to a i.mx RT 1062.

The device works fine with the debugger connected, but when the device is cold booted from QSPI flash, MMC device initialization fails reading the Extended CSD register.

-Tom

[kerryzhou]

Hi Will L and David Rodgers,

  That's for David Rodgers's reply about the cache issues, at first, I also suspect the cache issue. I also suspect Will didn't download code the external flash, just the RAM or SDRAM, then when power off and power on the code again, the code will be lost, but debug mode has no problem.

  From Will's last reply about the build result:

Memory region Used Size Region Size %age Used

BOARD_FLASH: 600088 B 96 MB 0.60%

SRAM_DTC: 112624 B 128 KB 85.93%

SRAM_ITC: 0 GB 128 KB 0.00%

SRAM_OC: 0 GB 256 KB 0.00%

BOARD_SDRAM: 0 GB 64 MB 0.00%

 It seem the code also download to the external flash.

 Will L, could you please give me your debug screenshot, I want to double check your code location:

Whether the code location in the 0X6000XXXX? This is the external flash memory range.

About the cache, please check your code, whether you call SCB_EnableDache or SCB_EnableICache?

Waiting for your updated information.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[william_lyons]

Kerry,
I'm not sure why you keep thinking the code isn't running.  As stated several times before, every other aspect of the code executes without the debugger, including the serial console, the SPI buses, the UARTs, the GPIO, the timers, etc.  I see the expected crawl of messages on the terminal program.  I can query the external RTC for the time and it reports back correctly (via the NXP).  I can use the NXP to poll the other devices connected to it and they all respond the same with and without the debugger connected.  The SD card read itself is triggered by a command I send to the NXP using the serial console, and it acknowledges receipt of the command before hanging in the section of code mentioned previously.  It really is _ONLY_ the SD card that appears to behave differently.

As for the cache functions mentioned, it looks like they are called inside \device\system_MIMXRT1052.c which according to breakpoints set in the debugger runs prior to the code reaching main().  Both functions appear to have been called.

I put a screenshot of my debugger session below, showing main() at 0x60058f6e.

-Will

[kerryzhou]

Hi Will L,

   Thank you for your detail information and the confirmation.

   Now, could you do this testing, copy your project, comment other modules code, just leave the SD card code and the GPIO code, whether the still problems?

  If yes, do you have the NXP official MIMXRT1050-EVKB board? If you have it, can you modify your code, eg, the SD card pin to match the MIMXRT1050-EVKB board, then download the code to the NXP offiical board, whether you can reproduce the problems or not? If you can porting your issue SD card code to the MIMXRT1050-EVKB board, and reproduce the problem, then you can send it to me, I will help you to test it, and check the details, just try to find the root problems.  Because I don't have your customer board, that's why I want to reproduce it in the MIMXRT1050-EVKB board, and also want to check whether it is related to the hardware.

   Thanks a lot for your understanding.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[william_lyons]

Kerry,

I have already tried commenting out as much of the extra code as I can and the problem persists.  I do not have ready access to the development kit at this time, and the differences would be significant enough that it would be comparing apples to oranges - and at the end of the day I need to get the SD car working on the new board anyway.

Circling back to my original question: What happens execution-wise when the debugger is connected and monitoring the microcontroller that doesn't happen otherwise?  Are there certain clocks that are altered? Are certain power modes overridden?  Is there some other affect on registers or timing that might explain why the code appears to work in every single other way except this one piece of the SD card driver?

-Will

[kerryzhou]

Hi Will L,

  Please give me your smallest project, which already comment other code, just leave the SD card code which can reproduce the problem, I will try to test it on my MIMXRT1050-EVKB board, I need to reproduce the problem, then I can check more detail.

  BTW, do you enter the low power mode?

  Share your smallest project which can reproduce the problem at first.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[dmarks_ls]

I ran into issues with the SD/MMC stack on the RT1050, and eventually found that the data cache was the issue.  The NXP-provided examples work fine because they use SRAM_DTC exclusively, which is designated non-cacheable.  As soon as I used SRAM_OC or BOARD_SDRAM as memory for storing the MMC data structures, the extended CSD read during initialization would return all zeroes.  Putting the mmc_card_t structure in non-cacheable memory fixed the initialization issue, but FatFS still didn't work right. so my workaround was to disable data cache globally.  See my thread here.

Try adding a call to L1CACHE_DisableDCache() after BOARD_ConfigMPU() during system start, and see if that affects the behavior.  If it doesn't, then you've at least eliminated that possible cause.

David R.

[william_lyons]

David,

I do not see any call to BOARD_ConfigMPU() in the code base.  The function is declared in a board.c file, but that is the only place it appears (other than the corresponding .h file).  I'm not sure if it was in the original SD Card example I started with or not, but it definitely is not being called in the current code base.

-Will

[dmarks_ls]

Somewhere in your project, the Cortex-M7 MPU should be initialized.  Regardless, as you indicated above, all of your data resides in SRAM_DTC, so you're not experiencing any cache-related issues; thus your problem lies elsewhere.  Hopefully the NXP engineers can give you some additional insight.

David R.

[kerryzhou]

 Hi Will L

 Do you have the NXP official board MIMXRT1050-EVKB, can you reproduce the problem on the nxp board?

  Where you download the code? external memory or the SD card? Or you just download the code to the external flash memory, and use the SD card to save the data?

  Please give me more details, thanks!

Waiting for your updated information.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[william_lyons]

Hi Kerry,

As mentioned above, this is for a custom PCB so the code cannot run on the evaluation kit board due to different pin/port usage.  The code is downloaded to the microcontroller's internal(?) storage and the SD card is going to be used only for data storage (logging).  It seems strange to me that the only difference between working and not working is the use of the debugger...

-Will

[kerryzhou]

HI Will L,

   Do you mean you download the code to RT internal memroy, eg internal RAM? Not External QSPI flash or hyper flash?

  If you just download the code to the internal RAM, then your phenomena is totally correct, when you connect the debugger and download the code, it works, because the code run from RAM.

  But if you power off and power on the board again, your code can't work, because your RAM code is lost, as you know RT1050 don't have the internal flash, you need to connect the external memory through flexSPI.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[william_lyons]

Kerry,

I'll have to double check the specifics, but I know that the code is getting stored and is running correctly.  I have the serial console connected to a PC and I can see all my lovely printf() statements display as the boot progresses and the software does its thing.  As mentioned, I then use that serial console to issue a command to the microcontroller to read and display one block worth of data from the SD card.  With the debugger session running, or immediately after, the data is displayed correctly and execution continues normally.  Without the debugger connected, I've traced through the command execution by inserting printf() markers and it hangs in the above mentioned section of the NXP SD card driver.  If I then use the "attach to running target" option of the debugger I can pause the processor and confirm that the trace shows it is stuck in the do/while loop.

-Will

[kerryzhou]

Hi Will L

  You still didn't tell me where you download the code, the qspi nor flash? hyper flash? or nand flash? Do you also use the SDRAM?

  Please give me more details, then I can help you to check it.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[william_lyons]

Kerry,

I do not know the answers to these, but I know that the board designer copied a lot from the evaluation kit so my assumption is that we're using the same memory storage scheme it uses.  I do know that the program is being stored in non-volatile as it survives a hard power cycle.  I also know that the MCUXpresso project began life as one of the software examples for the evaluation kit and was then slowly transformed as time went on to use the newer features and adjusted mappings on the custom PCB.  Based on the console output when I compile the project, it does not appear that the SDRAM is used at all, shows up as zero percent.

-Will

Memory region Used Size Region Size %age Used

BOARD_FLASH: 600088 B 96 MB 0.60%

SRAM_DTC: 112624 B 128 KB 85.93%

SRAM_ITC: 0 GB 128 KB 0.00%

SRAM_OC: 0 GB 256 KB 0.00%

BOARD_SDRAM: 0 GB 64 MB 0.00%

Finished building target

[dmarks_ls]

If you're using SRAM_DTC exclusively for data, then you're not having a data caching issue.  So my reply below doesn't really apply to you (until you start using other memories, which you'll need to if you're at 86% usage).