• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 782 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.

How to set virtual breakpoints?

Anne Thomas
Prodigy 180 points
Other Parts Discussed in Thread: MSP430FG4618

Dear TI Community:

I am new to the MSP430 and have recently started using the MSP430FG418/F2013 experimenter's board for learning purposes. I am trying to understand how the capacitive touchpad works. I looked at the "Hands-On Capacitive Touch" slide-show pdf, but did not find it very helpful for my purposes. I want to better understand how the capacitive touchpad works - the relationship between direction of finger trace and the number displayed on the LCD.

Specifically, I want to get the lcd to increment as I trace a "4" clockwise and to get it to decrement as I trace counter-clockwise.

I want to step through the demo code F2013 touchpad.c (contained in the Capacitive Touchpad folder as part of slac129a.zip)  to try to understand how the touchpad works. However, I am hindered by the number of hardware breakpoints I can use. The debug window generated the message "Virtual breakpoints can be enabled in Options dialog under Debugger->FET Debugger->Breakpoints.

I was able to set virtual breakpoints under project -> options -> fet debugger. Then I rebuilt and downloaded my project. However, the cursor does not point to ‘void main()’ as before. The target seems to continue to run and am still not able to step through code as I would like.

Could you please tell me how to set up the debugger such that I can step through the code as I would like? Alternatively, could someone explain how this code is working - the relationship between direction of finger trace and the number displayed on the LCD? I think that once I understand this, making the needed modifications for incrementing/decrementing should be fairly straightforward.

·     

 

 

  • 0
    Guru 227245 points

    The MSP can only handle a limited number of hardware breakpoints. The number varies with the MSP you use.

    But if you want to step through the code, you can use single-stepping. This way, only one breakpoint is required for the next step.

    About the program, I remember dimply that there are two different touch applications. One uses the 'cross' in the '4' as exactly that (so the diagonal bar on the 4 is unknown to the code and disturbs the operation when touched) while the other uses the diagonal bar of the 4 as a slider.
    But that's just a dim memory from browsing the descriptions once upon a time.

  • 0 in reply to Jens-Michael Gross
    Prodigy 180 points

     Thank you for the information.

    It seems that the touchpad code (F2013 touchpad.c) for the MSP430FG4618/F2013 experimenter's board is using the "cross" approach.

    I was trying to use the "run to cursor" feature on the IAR IDE as an alternative to single-stepping. Do you see any problem using this feature? Are there any operations not being performed by the debugger which may not be immediately obvious?

  • 0 in reply to Anne Thomas
    Guru 227245 points

    Anne Thomas said:
    I was trying to use the "run to cursor" feature on the IAR IDE as an alternative to single-stepping.


    I just came across a similar thread and had an idea (or rather two): read there.

    Anne Thomas said:
    Do you see any problem using this feature?

    I got the same board some weeks ago, but didn't have any time rto play with it right now, so I have no first-hand experience.

    Anne Thomas said:
    Are there any operations not being performed by the debugger which may not be immediately obvious?

    Lots. The debugger is an intrusive tool. It#s use (watchpoints, breakpoints etc.) affect everything that is related to realtime. And the capacity sensor IS realtime. Halting the clocks of the MSP may seem to freeze the time for the software, but the external hardware continues, charging or discharging the sensor etc. So whenever the debugger does anything, you can no longer trust your readings. If you keep this in mind, you should not have too many problems and no unresolveable ones.

**Attention** This is a public forum