• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 82 subscribers
  • Views 835 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.

TMS320F28379D: SD card example built successfully but could not access SD card

Minh Duc Tran
Prodigy 70 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,

I am new to TI microcontroller and after having managed to create a project from scratch to run the SD card example on the IDDK R2.2.1 board with the Delfino TMS320F28379D controlCARD R1.3, there is an error that I could not resolve. When I try to command the program to access/read/write to the card, it always jump to the ILLEGAL_ISR (from wait_ready in mmc_F2837x.c).

Except for creating a new CCS project to include the source code, I did not change any line of the example code.

I have tried to format the SD card by FAT32 or exFAT using PC but it would not help. Below are some screenshot about the error and linked resource.

The example location is "C:\ti\c2000\C2000Ware_MotorControl_SDK_3_02_00_00\c2000ware\device_support\f2837xd\examples\cpu1\sd_card\cpu01"

Thanks and best regard!

  • 0
    Prodigy 70 points

    Hello,

    To update, I have resolved the problem by having changed the project configuration from FLASH to RAM build.

    Regard!

  • 0 in reply to Minh Duc Tran
    TI__Guru 54445 points

    Thanks for the update. ILLEGAL_ISR issues associated with running from flash often correspond to a missing memcpy to copy the ramfuncs section (which contains the underlying function used in DELAY_US) from flash to RAM. I believe the InitSysCtrl() function already contains the memcpy as long as you make sure to have _FLASH in your predefined symbols. That's the first thing I would recommend checking if you want to try to get the flash build working.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    Hi Whitney,

    Thanks for your response. The RAM configurations have fixed my issues now. Therefore, I will try to get the FLASH build working in the future and update to you at that time.

    Sorry for late reply.

    Duc

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    Hi Whitney,

    Back to the SD card project, I am developing a dual-CPU program to write to SD card from CPU2. However, after having managed to build it successfully, CPU2 project also jumped to the ILLEGAL_ISR in the f_mount function. I have struggled for some days but could not find the cause.

    Thanks and best regard!

    Duc

  • 0 in reply to Minh Duc Tran
    TI__Guru 54445 points

    If you single step through the code, is there a particular line at which it jumps to the ILLEGAL_ISR? You are executing from RAM in this case?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    Yes, I am executing from RAM in this case.

    And following is the screenshot of debug windows, I could go single step in this code and if I move one step forward, it jumps to the ILLEGAL_ISR. The line caused error here might be 820 in ff.c (FATFS *fsobj), it allocated a FATFS struct pointer here and I do not know why it could go wrong

    Duc

  • 0 in reply to Minh Duc Tran
    TI__Guru 54445 points

    In the Debug panel in CCS, it usually shows you your call stack. What does it show when you're in the ILLEGAL_ISR?

    Can you check for signs of a stack overflow? That's a frequent cause of ITRAP issues. You should be able to look at the stack in the memory browser in CCS. If you're having trouble telling if it's overflowing, you can use the "Fill Memory" tool in the Memory Browser to fill the stack with a pattern before you run your application and then you can go to the end of the stack to see if the whole pattern got wiped out.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    At first, the stack of program in both CPU was allocated with RAMM1 section, origin = 0x000400 and length = 0x000400. Following is the screenshot of call stack when I was in the ILLEGAL_ISR

    I had filled the stack with 0xFF and some blocks were modified.

    And then I edited the RAMM1 with length = 0x000700. Following is the screenshot

    Do you think there is any sign of a stack overflow here? I'm sorry that I do not have any experience about it.

    Duc

  • 0 in reply to Minh Duc Tran
    TI__Guru 54445 points

    No, I don't think that is stack overflow--that looks like normal stack usage to me.

    If you click on the line that says "main()" in the Debug panel, what line does it show you?

    Do you have any interrupts enabled?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    It is the f_mount function that then leads to ILLEGAL_ISR. The first screenshot I showed you above captured when I stepped into it.

    There is an interrupt enabled here, the FatFs tick timer.

    Duc

  • +1 in reply to Minh Duc Tran
    TI__Guru 54445 points

    Since this is CPU2, it could be a permissions issue. Can you make sure CPU2 has permission to execute code from the memory where f_mount() is stored? It looks like it's in one of the GSRAMs which are shared between the CPUs. If CPU1 owns this RAM block, it would explain why the code appears valid but can't actually be fetched by CPU2. See the memory configuration registers in the technical reference manual for more details.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 70 points

    I have done some memory configurations to assign full access to CPU2 and it worked

    Thank you very much for your support!

    Duc