• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 247 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5964: Multiple breakpoints being generated for a source line

Andrew McLaren
Intellectual 570 points
Part Number: MSP430FR5964
Other Parts Discussed in Thread: MSPWARE, MSP430FR5994

Since I've upgraded to CCS 10.4, I've had a few cases where resuming from a breakpoint  doesn't appear to do anything, until it is resumed a second time.

In all cases, the breakpoint has been placed on a function call (or at least that is the only place I've seen it to date), but it is definitely not on all function calls.

I'm still trying to understand this, but I'll try and explain what I am seeing, with references from a specific example.

- The code breaks at a breakpoint, and the top of the debug stack shows MLX_Test.c:207 0x004710

- Hitting resume at this point appears to do nothing, but examining the debug stack shows MLX_Test.c:207 0x00471C, ie, a few bytes on, but still the same source line

- A peek at the disassembly around the call shows;

00470e: 2019 JNE (0x4742)

207 status = MLX_Read (&ctx->mlx_context,...

004710: 013C 0016 MOVA 0x0016(SP),R12

004714: 00AC 000A ADDA #0x0000a,R12

208 &ctx->read_data,

004718: 013E 0016 MOVA 0x0016(SP),R14

207 status = MLX_Read (&ctx->mlx_context,...

00471c: 1800 41D1 0016 0004 MOVX.A 0x00016(SP),0x00004(SP)

004724: 1800 40F1 462A 0000 MOVX.A #0x0462a,0x00000(SP)

I won't pretend to understand what is happening here, but it seems to have associated the 207 source line to two places in the memory listing (0x4710, an 0x471C), and is managing to break on both of them. 

This is using the GCC toolchain on CCS 10.4, with an MSP430 target. The code has come straight from a CCS 9 environment, and have no recollection of ever seeing this previously.

Any clues on what is happening here?

Andrew

  • 0
    TI__Guru**** 420660 points

    Hi Andrew,

    Could you provide a reproducible test case? Something I can try running on my FR59x target? It doesn't have to be your actual project, just something simple where the issue can be reproduced (the simpler the better). I would need the *.out and source files at minimum. If you do not wish to share on this public forum, please start a private E2E conversation with me.

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 570 points

    Hi Ki,

    I'll have a play seeing if I can reduce this to something simple - but my track record with these sorts of issues seems to result with the simplification masking or fixing the problem.

    I do have a test case running that was built to validate some logic that interfaces to an MLX temperature sensor, which does exhibit the problem (and should not be dependent on having a physical MLX connected). This does include a build stack that includes MSPWare, plus a lot of our own lower level logic. You are welcome to that, but would rather give you something easier to digest! Give me a few days and I'll see if I can reproduce this with something simpler.

    Andrew

  • 0 in reply to Andrew McLaren
    TI__Guru**** 420660 points
    Andrew McLaren said:
    but would rather give you something easier to digest! Give me a few days and I'll see if I can reproduce this with something simpler.

    Thanks Andrew. I only have access to a FR59x launchpad so it would be ideal if the application was as simple and generic as possible. I don't even need to be able to fully run the application, I just need a place to reproduce the breakpoint issue and that's it.

  • 0
    Guru 92251 points
    Andrew McLaren said:
    This is using the GCC toolchain on CCS 10.4, with an MSP430 target. The code has come straight from a CCS 9 environment, and have no recollection of ever seeing this previously.

    With the example which shows the issue, in both CCS 9 and CCS 10.4 can you open the Scripting Console (CCS menu View -> Scripting Console) and post the output from running:

    eval("DEBUG_DumpBreakpoints()")

    That causes the CCS debugger to dump which breakpoints have been set.

    With CCS 10.4, GNU v9.3.1.11 and a MSP430FR5994 I tried to create an example which showed the same issue of two breakpoints being set on one source line, but failed.

    Andrew McLaren said:
    I won't pretend to understand what is happening here, but it seems to have associated the 207 source line to two places in the memory listing (0x4710, an 0x471C), and is managing to break on both of them

    I think that is key to the issue, and my attempt to create some example code which did the same failed.

    That can sometimes occur with compiler optimisation. Can you also show the compiler options used?

  • 0 in reply to Chester Gillon
    Intellectual 570 points

    I've tried some radical simplification, but naturally it doesn't want to play ball, as the problem immediately disappeared!

    But one interesting thing came to light. I have found two cases in different executables which exhibit this, but both are calling the same function. I created a carbon copy of the function under a new name, and calling that also exhibited the problem. This (possibly) indicates it is related to the signature of the function in some way, or its processing stack, though my radical simplification used the same function call, but without issues. A function with an almost identical signature in the same library doesn't show the problem.

    None of the code is running with any optimisation (-O0 in all cases).

    Now on to the breakpoint dump. I've also included the source lines where the breakpoint is located, plus the disassembly around this source. I left only the one breakpoint active to try and reduce the noise. The following line is interesting, as it seems to show two hardware addresses for source line 219, which match what the disassembly shows. Adding another breakpoint only shows a single address. 

    MSP430: Breakpoint Manager Dump: Location: ../trunk/MLX_Test.c, line 219 ("C:\Data\Projects\Software\Micro\Common_Tests\MLX_Test\MLX_Test.out") (0x46f4) (0x4700)

    Andrew

    MSP430: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 12

    MSP430: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 6

    MSP430: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0

    MSP430: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0

    MSP430: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Enabled: 2

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Hardware Configuration

    MSP430: Breakpoint Manager Dump: Location: "C$$IO$$" (0xcc4a)

    MSP430: Breakpoint Manager Dump: Debugger Response

    MSP430: Breakpoint Manager Dump: Condition:

    MSP430: Breakpoint Manager Dump: Skip Count: 0

    MSP430: Breakpoint Manager Dump: Current Count: 0

    MSP430: Breakpoint Manager Dump: Action: Process CIO

    MSP430: Breakpoint Manager Dump: Miscellaneous

    MSP430: Breakpoint Manager Dump: Group: Default Group

    MSP430: Breakpoint Manager Dump: Name:

    MSP430: Breakpoint Manager Dump: Breakpoint set by the system

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Hardware Configuration

    MSP430: Breakpoint Manager Dump: Type: Simple

    MSP430: Breakpoint Manager Dump: Action: Halt Target

    MSP430: Breakpoint Manager Dump: Trigger 0: Memory Address Bus

    MSP430: Breakpoint Manager Dump: Location: ../trunk/MLX_Test.c, line 219 ("C:\Data\Projects\Software\Micro\Common_Tests\MLX_Test\MLX_Test.out") (0x46f4) (0x4700)

    MSP430: Breakpoint Manager Dump: Mask: 1048575

    MSP430: Breakpoint Manager Dump: Operator: ==

    MSP430: Breakpoint Manager Dump: Access: Instruction fetch

    MSP430: Breakpoint Manager Dump: Trigger 1: None

    MSP430: Breakpoint Manager Dump: Debugger Response

    MSP430: Breakpoint Manager Dump: Condition:

    MSP430: Breakpoint Manager Dump: Skip Count: 0

    MSP430: Breakpoint Manager Dump: Current Count: 0

    MSP430: Breakpoint Manager Dump: Action: Remain Halted

    MSP430: Breakpoint Manager Dump: Miscellaneous

    MSP430: Breakpoint Manager Dump: Group: Default Group

    MSP430: Breakpoint Manager Dump: Name: Breakpoint

    MSP430: Breakpoint Manager Dump: Breakpoint set by the user

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Disabled: 3

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Hardware Configuration

    MSP430: Breakpoint Manager Dump: Location: "C$$EXITE"

    MSP430: Breakpoint Manager Dump: Debugger Response

    MSP430: Breakpoint Manager Dump: Condition:

    MSP430: Breakpoint Manager Dump: Skip Count: 0

    MSP430: Breakpoint Manager Dump: Current Count: 0

    MSP430: Breakpoint Manager Dump: Action: Terminate Program Execution

    MSP430: Breakpoint Manager Dump: Miscellaneous

    MSP430: Breakpoint Manager Dump: Group: Default Group

    MSP430: Breakpoint Manager Dump: Name:

    MSP430: Breakpoint Manager Dump: Breakpoint set by the system

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Hardware Configuration

    MSP430: Breakpoint Manager Dump: Location: "C$$EXIT"

    MSP430: Breakpoint Manager Dump: Debugger Response

    MSP430: Breakpoint Manager Dump: Condition:

    MSP430: Breakpoint Manager Dump: Skip Count: 0

    MSP430: Breakpoint Manager Dump: Current Count: 0

    MSP430: Breakpoint Manager Dump: Action: Terminate Program Execution

    MSP430: Breakpoint Manager Dump: Miscellaneous

    MSP430: Breakpoint Manager Dump: Group: Default Group

    MSP430: Breakpoint Manager Dump: Name:

    MSP430: Breakpoint Manager Dump: Breakpoint set by the system

    MSP430: Breakpoint Manager Dump:

    MSP430: Breakpoint Manager Dump: Hardware Configuration

    MSP430: Breakpoint Manager Dump: Location: "C$$IOE$$"

    MSP430: Breakpoint Manager Dump: Debugger Response

    MSP430: Breakpoint Manager Dump: Condition:

    MSP430: Breakpoint Manager Dump: Skip Count: 0

    MSP430: Breakpoint Manager Dump: Current Count: 0

    MSP430: Breakpoint Manager Dump: Action: Process CIO

    MSP430: Breakpoint Manager Dump: Miscellaneous

    MSP430: Breakpoint Manager Dump: Group: Default Group

    MSP430: Breakpoint Manager Dump: Name:

    MSP430: Breakpoint Manager Dump: Breakpoint set by the system

    // Source line where breakpoint set

    (219) status = MLX_Read (&ctx->mlx_context, request_address, request,

    &ctx->read_data,

    &_nextTest,

    ctx);

    // Disassembly around line 219

    0046f2: 2019 JNE (0x4726)

    219 status = MLX_Read (&ctx->mlx_context, request_address, request,

    0046f4: 013C 0016 MOVA 0x0016(SP),R12

    0046f8: 00AC 000A ADDA #0x0000a,R12

    220 &ctx->read_data,

    0046fc: 013E 0016 MOVA 0x0016(SP),R14

    219 status = MLX_Read (&ctx->mlx_context, request_address, request,

    004700: 1800 41D1 0016 0004 MOVX.A 0x00016(SP),0x00004(SP)

    004708: 1800 40F1 462C 0000 MOVX.A #0x0462c,0x00000(SP)

    004710: 0ECF MOVA R14,R15

  • 0 in reply to Andrew McLaren
    TI__Guru**** 420660 points
    Andrew McLaren said:
    None of the code is running with any optimisation (-O0 in all cases).

    Note that 0 level optimization is still some optimization. No optimization would be -Ooff. Can you try no optimization?

  • 0 in reply to Ki
    Intellectual 570 points

    The GCC 9.3.1 compiler shipped with 10.4 definitely doesn't support -Ooff. The CCS optimization properties window tags -O0 as "None". I tried leaving any compile options off (which should be the same as -O0), but no change.

    However, there is an -Og (optimize for debugging). The documentation is a little vague on exactly what this does, other than

    Optimize debugging experience. ‘-Og’ should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than ‘-O0’ for producing debuggable code because some compiler passes that collect debug information are disabled at ‘-O0’.

    Sounded like what I should be using in any case, so switched the complete compile tree to this, and it cured the problem. I'm guessing that some of the debug information suppressed at -O0 is what was causing the confusion in the debugger?

    I don't know if this indicates any underlying problem or not. If this is something that should be left open, let me know, otherwise my immediate issue is resolved and happy to close it off.

    Thanks for the help as always!

    Andrew

  • 0 in reply to Andrew McLaren
    TI__Guru**** 420660 points
    Andrew McLaren said:
    The GCC 9.3.1 compiler shipped with 10.4 definitely doesn't support -Ooff. The CCS optimization properties window tags -O0 as "None". I tried leaving any compile options off (which should be the same as -O0), but no change.

    Ah, you are absolutely correct. Sorry, I was thinking of the TI compiler, not GCC

    Andrew McLaren said:
    Sounded like what I should be using in any case, so switched the complete compile tree to this, and it cured the problem. I'm guessing that some of the debug information suppressed at -O0 is what was causing the confusion in the debugger?

    Yes this does indeed appear to be the case. 

    Andrew McLaren said:
    I don't know if this indicates any underlying problem or not

    I'm not sure either. I will need to explore this. I understand the debug vs optimization tradeoff, but I would not expect the debug behavior you were witnessing, especially if this didn't happen on older CCS versions when building the same project with the same optimization level...

  • 0 in reply to Ki
    Intellectual 570 points

    Thanks Ki.

    Can I do any more to help with this, or should I just close it off?

    Andrew

  • +1 in reply to Andrew McLaren
    TI__Guru**** 420660 points

    I think we can close this issue. I will file a task to myself to investigate further regarding the "double halt" behavior.

    Thanks

    ki

**Attention** This is a public forum