• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 173 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

LP-AM263P: SDMMC Example Projects Fail

TMDSCNCD263P: MMC/SD Examples Fail

stomp
Genius 4705 points

Part Number: TMDSCNCD263P
Other Parts Discussed in Thread: SYSCONFIG

Hi,

I recently posted on this topic regarding failures of the MMC/SD examples on a LP-AM263Px. This is in addition to a large post regarding failure of etherent examples, which was fixed with a patch from TI.

We purchased new hardware and still have the same failures. We have tested multiple SD cards with different file system formats and different partition options, none work.

All examples appear to ID the card correctly, but fail after switching to 4bit mode.

The output from the test we get is:

[Cortex_R5_0] [MMCSD FILE IO] Starting...
Some tests have failed!!

 

Our SDK is mcu_plus_sdk_am263px_11_01_00_19 and the example in question on this board is mmcsd_file_io_am263px-cc_r5fss0-0_freertos_ti-arm-clang, however all other examples we have tested, including the raw examples fail in the same way.

 

Hopefully someone from TI can shed some light on why the tests fail, and maybe even confirm if there is an issue in the driver code when switching to 4 bit mode.

 

Thanks.

 

 

  • 0
    TI__Guru**** 200206 points

    Hi stomp,

    Most Likely Causes
    1. Wrong Board Variant Example

    Your example name is mmcsd_file_io_am263px-**cc**_r5fss0-0_freertos_ti-arm-clang — the -cc suffix is for the ControlCard, not the LaunchPad (-lp). Running the wrong board variant means the pinmux and hardware config in example.syscfg will be wrong for your actual board, which would affect exactly the data lines (D1–D3) that only matter in 4-bit mode.

    Check: Does a -lp variant of the example exist in your SDK?  ---> C:/ti/mcu_plus_sdk_am263px_11_01_00_19/examples/drivers/mmcsd/

    2. Pinmux for D1–D3 Lines

    Card ID only uses CMD + D0 + CLK (1-bit mode). Switching to 4-bit activates D1, D2, D3. If those pins are not correctly muxed in SysConfig, they will be floating or configured as GPIO. Check in example.syscfg: Verify all 4 data lines (D0–D3), CMD, and CLK are assigned and muxed to the MMCSD peripheral — not left as default GPIO.

    3. Force 1-Bit Mode to Confirm

    As a diagnostic, you can temporarily force the driver to stay in 1-bit mode. In the SysConfig MMCSD module, look for a bus width setting and force it to 1-bit. If the test passes, this confirms the issue is in the 4-bit transition (pinmux, hardware, or driver).

  • 0 in reply to QJ Wang
    Genius 4705 points

    Hi QJ,

    1. We have purchased both LP and CC hardware. I can confirm the LP is running on the Red LaunchPad and CC on the green control card. Yes both the CC and LP examples are in the examples/drivers folder.

    2. We have been through the datasheet for the pin mux configurations for both boards.I don't recall us noticing a difference for the data lines as it is the same CPU package. Either way we have manually confirmed the PinMux values are correct.

    3. During MMCSD_open(), we manually forced the .auBusSpeed = 1 (Assuming this means bus width). The driver can ID the card, but the test still fails as before on both boards with the two different firmware binaries.

    Thanks.

  • 0 in reply to stomp
    TI__Guru**** 200206 points

    Hi Stomp,

    I did a test with a HC1 16GB SD card before, the example works on both CC and LP. If you run cc example on cc card or lp example on LP board, you don't need to reconfig the pinmux. All the examples are tested before released. 

    AM263Px MCU+ SDK: Release Notes 11.00.00

    Have you tried a lower MMCSD clock frequency? Do you have any a basic SD card for example class 10 or the SD card come with CC and LP to try?

  • 0 in reply to QJ Wang
    Genius 4705 points

    Hi QJ,

    In the driver function MMCSD_parseCSDSd() there is a bug.

    Here is its description of the fix we had to make to get FreeRTOS+FAT to recognise the partition.

    // 2026-03-24: On the AM263PX, the MMCSD controller
// stores the R2 (136-bit) response with CSD bits already aligned to the correct
// positions in RSP76/RSP54/RSP32/RSP10. The original TI code shifted all 4 DWORDs
// left by 8 bits to compensate for CRC stripping, but on the AM263PX this shift
// is NOT needed and causes all CSD field extractions to read wrong bit positions.
//
// Verified empirically: resp[3]=0x400E0032 gives CSD_STRUCTURE=1 (SDHC v2.0),
// TRAN_SPEED=0x32 (25MHz), WRITE_BL_LEN=9 (512B) -- all correct WITHOUT shift.
// With shift: CSD_STRUCTURE=0, WRITE_BL_LEN=0, TRAN_SPEED=0x5B -- all wrong.
//
// Register mapping (AM263PX, no shift needed):
//   resp[3] = RSP76 = CSD[127:96]
//   resp[2] = RSP54 = CSD[95:64]
//   resp[1] = RSP32 = CSD[63:32]
//   resp[0] = RSP10 = CSD[31:0]

    In my last message I suspected the fault occurred during a switch to 4 bit mode, this was incorrect.

    Thanks/