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/MSP-EXP430FR5994: If attempt to step over a MSP430 "CALLA &abs20" function call in CCS 8.3, the debugger seems to free-run rather than stepping over

Part Number: MSP-EXP430FR5994
Other Parts Discussed in Thread: MSP430FR5994

Tool/software: Code Composer Studio

The TI compiler MSP430 run-time-library contains _lock and _unlock function pointers to be able to insert mutual exclusion. The compiler generates a  "CALLA &abs20" instruction to call these function pointers.

Using CCS 8.3.0.00009 with TI MSP430 tool-chain 9.0.1 found that trying to step over calls to such function pointers seems to cause the debugger to free-run until the next breakpoint, rather than stepping over the function call.

Using the attached example which can run on a MSP-EXP430FR5994:

1. Start a debugging session, and set a breakpoint on the line following the first malloc() call:

2. Step into the malloc() call.

3. Step until get to the _lock() call in malloc:

4. Use Step Over, which is expected to step to the text statement in malloc(). However, the Step Over causes the program to run to next breakpoint which was set in the main function:

Is this a bug, or the expected behaviour?

3058.MSP430FR5994_max_heap_size.zip

  • Thank you for the excellent (as always) testcase. I can reproduce the issue with the provided executable, and also when I rebuild with 18.1.5LTS.

    It is as you say, a source step over at that location causes the target to simply run instead of stepping over to the next line. If you source step in and the step over, you can continue to step over.

    As for your question - is it a bug? I'm not sure. I will need some of the debugger experts to investigate further.

    Thanks
    ki
  • Ki-Soo Lee said:
    As for your question - is it a bug? I'm not sure. I will need some of the debugger experts to investigate further.

    It's a bug. I filed one for for it. Tracking ID: CCBT-2415

    In summary, the step breakpoint is not being set on the correct address. Hence the step breakpoint is missed and the target just continues to execute.

    Thanks again for the excellent test case and the detailed analysis.

    ki