Unable to set any valid breakpoints for debugging

Follow
Avatar
Michael Carosino

Hi, I've got CrossWorks MSP430 Version 2.0.9.2010033104.7366, I'm trying to debug an application that I have modified (unfortunately I did not write the original application) for an MSP430F2272. The strange thing is, the original application compiles and debugs fine and and I can set and use breakpoints. However my application will compile and go to debug mode but wherever I set a breakpoint it has the red dot with a question mark in it meaning invalid breakpoint and so they never work...

 

As far as I can tell, my application is running fine on the hardware as I can communicate with it via serial, so it seems to just be debugging that is not working in this case. I've tried cleaning the project, removing all breakpoints, re-loading, etc to no avail.

0

Comments

10 comments

Sort by Date Votes
  • Avatar
    Simon Schwarz

    Exact same problem here!

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Are there any markers in the editor margin to be able to set a breakpoint? If not is the code built in debug mode?

    0
    Comment actions Permalink
  • Avatar
    Simon Schwarz

    Yes I can set the markers but as soon as the software is programmed and compiled they become question marks. The code is build in debug mode.

    0
    Comment actions Permalink
  • Avatar
    Simon Schwarz

    One addition: If I try to step through the code I get the following error message: "Cannot single step: Not enough hardware instruction breakpoints"

    There are no other additional breakpoints set - so there should be enough breakpoints available (Cortex-M3 LPC1788).

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Do you have software breakpoints enabled? The 2272 only has two hardware breakpoints. Use the breakpoints window to see if any breakpoints are set.

    0
    Comment actions Permalink
  • Avatar
    Simon Schwarz

    Hi Michael,

    Read-only Software Breakpoints: disabled
    Read-write Software Breakpoints: dynamic

    I have the problem on a Coretx-M3 with up to 8 hw breakpoints.

    In the breakpoints window only the CM Breakpoints are set - disabling them doesn't solve the problem.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    When you connect what does the output/transcript window report as the number of breakpoints available?

    0
    Comment actions Permalink
  • Avatar
    Simon Schwarz

    Hi,

    that was the right question ;)

    We identification failed - it seems that out reset circuit is does not work in some cases and the processor is in a state where it is not usable by JTAG. (the power is buffered by gold caps)

    The message was: Couldn't read debug information from ROM table.

    After switching of the whole system and unload the caps we get proper identification and working debugging:

    Cortex-M3 r2p0

    Num Breakpoints 6
    Num Watchpoints 4
    Identifying

     

    Thank you Michael!

    Everyone who has this problem: Switch on "Identify target on connect" (in Targets window the right upper arrow) - this was deactivated in our case.

    0
    Comment actions Permalink
  • Avatar
    Simon Schwarz

    sry - I need a edit function ;)

    The sentence should be: Identification failed - it seems that our reset circuit does not work in some cases and the processor is in a state where it is not usable by JTAG. (the power is buffered by gold caps)

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    DIFFERENT BUT SIMILAR

    This is a different problem but with somewhat similar symptoms, hence I've jumped onto this thread.

    CrossWorks for ARM
    Release 2.3.2.2013051717.18363
    Linux x86

    STM32F205.  CTL.

    When I first run an application for debugging, I can set breakpoints in main(), but not in most other files. As with Simon, the question-mark appears and the little arrows marking possible breakpoint locations disappear.

    When my situation differs is that I do have a working connection to the target, I can break, single-step, or run-to-cursor in main(), but can't in other files until I have single-stepped into that file ... then all the arrows appear and I can use all the breaking as above.  Another oddity of this that may give a clue, is that when I first single-step into that file it usually(? always?) opens a new copy and the old copy will still not allow breakpoints.

    Mostly this is just an irritation, as it doesn't take long to step into most files, however it's a particular problem with the IRQ file where I have no option to single-step into it first (though I may add a stub routine just to allow it for now).

    Has anyone any thoughts on how this might have come about?

    FWIW, a little while ago I had a problem with cross-coupling between related projects, and I deleted a file (IIRC "~/.rowley_associates_limited/CrossWorks for ARM/settings.xml"). It seems possible to me that this might be a similar problem.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post