• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 334 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.

CCS version: 4.1.1.00014 and using a XDS100v2 Rev A emulator debugging issue

mkeramaty
Intellectual 310 points

I am currently running CCS version: 4.1.1.00014 and using a XDS100v2 Rev A emulator.

I have succesfully built and ran a Bios based project for the dm6437 evm board but am having some trouble debugging properly.

When in any code that is kicked off from the main() function I have no issues and can halt the dsp, add variables to the watch window, etc. However, when I try to do the same in code that was spawned from a task its as though the system doesnt realize that code is running. It ignores breakpoints, and will not let me add variables to the watch window.

Is this a limitation of the emulator? Do I have something set up wrong?

Thanks

  • 0
    TI__Expert 8055 points

    I'm not sure what exactly is going on here, but this isn't a limitation of the emulator.  There's no reason that you shouldn't be able to do what you are intending.

    When you set the breakpoint, can you try doing it in the disassembly window, rather than the source window?  When you do it though source, it's relying on a symbol to be resolved to telling the emulator the address of where to put a breakpoint.. For code that isn't optimized, this works fine.  But if the code is signifnicantly optimizad, the symbol may not be getting resolved where you think it is. This shouldn't be the problem, I'm just trying to eliminate the possibility.

    What type of memory is the task code in?  If it's in non-volatile memory, like flash, you should specify to use a hardware breakpoint, rather than a software one.  You should make sure your memory map in CCS is correct.  This will resolve these types of issues, as the debugger will automatically try to use a hardware breakpoint if the memory is mapped as non-volatile.

    I assume that you are sure the code that you are setting the breakpoint in is getting executed. 

    You may not be able to add variables to the watch window while the code is running.  Let's see if this problem goes away once we're able to get it to halt at the breakpoint.