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.

RTOS/TM4C129DNCPDT: Firmware crash/halt when calling SDSPI_open API

Part Number: TM4C129DNCPDT

Tool/software: TI-RTOS

Hi Everyone,

Just to brief you about my task, currently I'm running my firmware on external flash/SRAM via EPI interface. I'm able to print via UART, do CAN communication etc. But when it comes to opening SD card interface(SDSPI_open), the firmware either halts or crashes (cannot debug when firmware is running on EPI interfaced memory). I verified that SD card IO's and EPI IO's are not conflicting.

I initially ran the same firmware in internal flash with the EPI interfaced SRAM/FLASH(Not active) and sd card access works fine.

I was wondering if SDSPI TIRTOS library have some clock limitations since the firmware in EPI interfaced memory is limited to 30MHZ.

Thanks in Advance.

-Prajnith

  • Prajnith Kumar said:
    cannot debug when firmware is running on EPI interfaced memory).

    I find that a little surprising. Are you sure? Is this documented somewhere?

    Even if that is true, it doesn't prevent you from debugging. Even with toggling a single pin you can quickly narrow the region where the failure occurs (as long as the act of searching doesn't alter the bug).

    Robert

  • Hi Robert,

    Thanks for the quick reply, well i had posted the issue of unable to debug (add breakpoints) when firmware is residing in external memory
    (e2e.ti.com/.../602028)
    and i got the response from TI forum member that its not supported due to M4 cortex memory addressing limitation of 1Gbits and i got the same answer from TI support.

    Regarding the current SD card issue, well i have UART prints enabled and i have placed prints before and after SDSPI_open function and during the execution, i dont get any prints after the SDSPI_open function call.

    Thanks,
    -Prajnith
  • Hi Robert,

    I found the issue , it was lame mistake. Well at the hardware end I was pulling the chip select to ground at the SD card module but in the code the SDSPI_open was internally considering a enum with Chip select as PORT C.7 which was mapped to EPI pin, so when ever SSI Pheripheral Clock enable api was called it would crash the Firmware. It was little difficult to debug since SDSPI_open was in a library and couldnot trace internally where the code was crashing.

    Thanks again for your time and support.

    -Prajnith