• Locked Locked
  • Replies 8 replies
  • Subscribers 58 subscribers
  • Views 2872 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.

Breakpoints stopping at wrong location

Samuel Wantman
Intellectual 370 points
Other Parts Discussed in Thread: MSP430FR5949

Hi,

I'm debugging a program which is behaving oddly, and I set a breakpoint to stop on 1509, but it stops 16 lines earlier at line 1493.  This is not an optimization issue because the place that it stops isn't even in the same subroutine and isn't even called anytime close to when the routine I'm trying to debug is called! Looking at the disassembly, the code is stopping at 0x010000.  It should have stopped at $010AD2.  Considering that both points in the code are in high memory,  I suspect that is the problem with CCS.  I've encountered this problem several times, in several places in my code.  Sometimes it stops before the location I've specified and sometimes it is after.  I am using the latest version of CCS6 programing an MSP430FR5949.  I'm using less than half the memory on the chip so far, and half of that is data storage.  Can I avoid this problem by not using high memory?  How do I tell CSS to stop using it?  I'm using GRACE.  Any help would be appreciated.  A fix would be nice, but I'd be happy with a workaround...  Thanks.

  • TI__Guru**** 472221 points
    Hi Samuel,
    Can you provide a small test case and attach it to this thread? If you do wish to share it publicly, please start a private conversation with me on the forums.

    Thanks
    ki
  • in reply to Ki
    Intellectual 370 points
    I never had this problem until my application grew in size. It is now about 10k of code and 24K of data storage. I would be happy to share the entire thing with you, (it is open source), but it is written for two pieces of specific hardware, so I doubt you'd get very far until the code is just waiting for a hardware interrupt. I did notice today that a breakpoint worked correctly the first time I tried it today, but the same breakpoint didn't work the second time (ended up at 0x010000 again). Is there a way to set up GRACE to ignore high memory? I haven't been able to. I tried specifying a small data model, but got dozens of errors when it tried to link.
  • in reply to Samuel Wantman
    TI__Guru**** 472221 points
    There was an old issue with odd breakpoint behavior and msp430 application using a large memory model... but that was resolved long ago with CCSv4.2. I can't imagine that is the issue here (though there are a lot of similarities it seems). You can tweak the generated linker command file to explicitly place your code where you wish. More information on how to do this is covered in the below wiki article:
    processors.wiki.ti.com/.../Linker_Command_File_Primer

    Thanks
    ki
  • in reply to Ki
    Expert 2300 points

    Hi,

    I experience the exact same behavior as Samuel above.

    If I set a breakpoint at any location, the program breaks at 0x010000 (see here)

    Since this problem began I notice another breakpoint related behavior that may be related: When I set a breakpoint and then loads and run the code, it halts at:

    CSTART_DECL _c_int00_noargs_noexit()

    at boot_special_4.4.c (see here)

    Hitting 'Run' halts me again at the ending brace of 

    Void ti_sysbios_BIOS_registerRTSLock(Void)

    at Projectname_pe430X.c (see here)

    Hitting 'Run' again frees the software and it actually start running (until hitting phony breakpoint @0x10000)

    I'm using MSP430 (like Samuel above..., but mine is F5259) and CCS 6.1.2.00015

    Needless to say that this is VERY disturbing in the last couple of weeks....

    Any advise would be appreciated.

    Thanks

  • in reply to Eyal Lasko
    Prodigy 40 points

    I experienced the same problem since my project grew to more than 64K codesize.

    A workaround was: Start the project and when it stops at 'main', clear all breakpoints and re-set them again manually. This was annoying enough.

    Since today I am not able to set any breakpoint at all.

  • in reply to Peter Teuchert
    Intellectual 370 points

    It would be nice if TI looked into this.  It has been two months that I have had to find alternate means of debugging my code.  This is really slowing me down!

  • Prodigy 60 points
    I experienced the same problem
  • in reply to montecrist9
    Intellectual 400 points

    I found the same problem myself and my colleague. The workaround is to set the following linker properties:

    CCS Build->ARM Linker->Advanced Options-> Linktime Optimization -> Eliminate sections not needed in the executable = OFF

    The code size increases, of course.