• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1456 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.

BIOS Resource Conflict Exception

auppu6547
Expert 3795 points
Other Parts Discussed in Thread: SYSBIOS

Hi,

I am trying to run a multi-core application for TCI6638 and the code crashes on all the cores stating that it's a resource conflict exception. When I checked the disassembly, it seems to exit in the ti_sysbios_family_xxx_Hwi_switchToTaskStack( ) API. 

Can anyone help me understand why it's failing in this API?

Thanks,

Arun

  • 0
    TI__Mastermind 20805 points

    Hi Arun --

    Can you try looking at the disassembly code for this function after the program is first loaded?   And then compare it to the same code when the program crashes?   I suspect that the code has become corrupted maybe from a bad write to the program space?  If if is a memory corruption, then you might be able to use the advanced emulation features to debug the problem.  You can configure the emulation module to halt on a write to a specific memory address which might help you catch the culprit.

    -Karl-

  • 0
    TI__Mastermind 32475 points

    Arun,

    Another thought is to check your ISR and Task stacks to make sure you have not blown the stacks.  This can be checked using ROV even after you've received the exception.

    Judah

  • 0 in reply to judahvang
    TI__Expert 3795 points

    Hi Karl & Judah,

    Thanks for the reply. I checked the Task stack in the ROV log and they seem to be within the stackpeak. 

    I also compared the disassembly of the function call before and after it crashes and it seems to be different. Here's a snapshot of the before and after disassembly. 

    Regards,

    Arun

  • 0 in reply to auppu6547
    TI__Mastermind 20805 points

    The disassembly looks OK to me.  The only difference is on the abort symbol where you see a software breakpoint in one case (SWBP) and not the other.  I don't know why those are different, but I don't think that's the problem.  The debugger puts SWBP on the abort symbol so that CCS will halt.   I think CCS has a mirror of the "real" opcode at that address and usually shows this in the disassembly window.

    Can you reproduce this on a WebEx?   I think that might be the more efficient thing to do.   Please schedule with Judah.

    Thanks,
    -Karl-