CCS Mac: Conditional Breakpoints Issue

MSP-FET430UIF also needed a firmware update. Tool was recognized, firmware update went smooth. basic debugging seems to work.

Waiting for info on the conditional break since either my settings were wrong or there is a problem.

The screenshot shows my current setting for a conditional break. the location (0x23BC) is the address of the variable 'min).

Using this settings will not allow to debug the program. Both eZ-FET and FET430UIF stop at a certain point (same source location) after RUN command with the error message shown in screenshot below

Tested two more tools: MSP-EXP430F5529 and MSP-EXP430FR5739 --> both were not recognized/non-functional
Both were using a TUSB3410 chipset in their eZ-FET tool

I think this is related to the USB VID and also in being CDC class devices.

The eZ430-F2013 is quite old (and limited to F20xx series), so I don't expect anybody will complain if this tool is not supported on OS X. All other tools need to be supported with the final release.

Just one question regarding USB VID 0x0451 support on OS X: Their is a signed driver for use with Energia (energia.nu/.../guide_macosx - energia.nu/.../MSP430LPCDC-1.0.3b-Signed.zip). Did anybody test this already?

I will give conditional breakpoints a try this morning.

I don't have any trouble connecting to my 5529 LaunchPad. It does the expected firmware update but otherwise works fine. It has the newer eZFET hardware on it as compared to the G2. The G2 is not supported on Mac or Linux. I will try to grab someone to help figure out what is going on with connectivity with your 5529.

John

I was able to get the breakpoint working ok. The type that you want to set is a "Watchpoint with Data". I had trouble getting this to work from the editor but I was able to set it properly from the breakpoints view.

If I go to the breakpoints view and click the little down arrow beside the "New Breakpoint" button (blue circle with a +). Then I select the Watchpoint with Data item. I enter in the name of my variable in the first box and then the value that the variable should have to trigger a break. I then run my program and it halts when the variable reaches that value.

To do it from the editor is a bit different. Here what I do is I double click on the variable I am interested in so that it is highlighted. Then I hold control and click the mouse. Then I select Breakpoint (Code Composer Studio) -> Watchpoint with Data. In this case the first box is the value that you want the variable to reach as it already knows the variable you are interested in.

Regards,
John

For the FR5739 I cannot get that one to work. I believe it uses the older eZ430 hardware. The 5529 is the newer version.

The error that I get with FR5739 is "No USB FET was found".  Is that what you see with the 5529?

Hi John,

just to be sure we're talking about the same things: I've tested with the MSP430F5529 EXPERIMENTERS BOARD (

) and NOT with the Launchpad (

).

Since I don't own a MSP-EXP430F5529LP I can't do any testings based on this!

Tried the conditional breakpoint again this morning with no luck! Testing both of your approaches (which is exactly the same what I did before make the initial post here) did not break as required/expected.

Breakpoint is not enabled after setting/configuring it. Trying to enable it results in the error message shown above.

HW breakpoint on RTC register access is also not working.

Adding a breakpoint and then trying to configure it into a 'watchpoint with data' results in a resource problem

The software I'm testing with is from here MSP-EXP430FR5969 Software Examples (Rev. C); it is the '430BOOST-SHARP96_ULP_FRAM' example

aBUGSworstnightmare

I will find a FR5969 and try to reproduce the breakpoint problem. I suspect that it has to do with it being a local variable that is not currently in scope (the PC is not in that function) but I will reproduce on Mac and Windows to confirm with the debugger guys. In my case I set the breakpoint on a global variable.

You are correct that the experimenters kit may have a the older MSP FET embedded on it and not the newer one that is on the LaunchPad.

Here is what I see:

The error message in your first capture "min does not resolve to an address" is due to min not being in scope at the time you are setting the breakpoint. The hardware breakpoint gets associated with an address. At the time you are trying to set it the location where that local variable is going to be placed is not known. If you were to step into the function so that the variable was in scope and on the stack then it would set ok.

In the second capture you are attempting to set the breakpoint on RTCMIN. When I am in main() and I try to view RTCMIN in the expressions view I get identifier not found. RTCMIN is defined in msp430fr5xx_6xx.h to be RTCTIM0_H I cannot set a watchpoint on RTCMIN but I can set one on RTCTIM0_H To set a watchpoint the symbol you are setting it on needs to resolve to an address. RTCMIN doesn't for me but TRCTIM0_H does as it is a memory mapped register.

For the 3rd error this happens when you run out of hardware breakpoint resources. I have been getting this message as well in my experiments. Depending on the device between 2 and 8 breakpoints are available. CIO is enabled by default which uses 1. Setting a watchpoint on a variable with a value would use 2 resources I believe. Stepping also uses up h/w breakpoint resources by default. You can enable "software" breakpoints but MSP430 doesn't have a breakpoint opcode so to mimic software breakpoints a hardware breakpoint resource is used but I believe it just uses 1 for that. However even after changing the settings and clearing my breakpoints I can get into a state where it gives me the message. I can get rid of it by terminating my debug session and starting a new one. I think there is something going wrong with breakpoint resources not getting released in the MSP driver stack. I am going to try to put a test case together so I can submit a bug.

Regards,
John

Looks like there are only 3 breakpoints for the memory bus on the FR5969 device:
www.ti.com/.../msp430fr5969.pdf

So the trick here is understanding how our limited resources are getting used.

So what is happening is that 1 resource is reserved so that software breakpoints can be used if hardware breakpoints run out. That leaves us with 2. So as soon as you set watchpoint with value you are now out of hardware breakpoint resources. If you set a breakpoint in source code at this time it will use software breakpoints. You will not be able to set any more watchpoints or hardware breakpoints.

Now if you set a breakpoint in source code first this will set a hardware breakpoint by default (this behavior can be changed via a setting). This takes you down to 1 available resource. If you try to set a watchpoint with a value now then it will fail and give you that message about disabling support for software breakpoints. You would be able to set a normal watchpoint without a value comparison.

Thus from what I am seeing the tool is working correctly, we just don't have much to work with in terms of breakpoints on this device.

Note that if your program uses CIO (printf...) which is not that likely on MSP430, then this would also use up a hardware breakpoint resources.

Regards,
John

Hi John,
thanks for the explanation, but from my point of the view the debugger is not working.
Tried the same on CCS5 (latest version) on Win7 with the same result (using same tool/software example): the debugger is not stopping on the 'watchpoint with data' when the variable is a local variable. I can have a breakpoint inside that function, showing that the variable get updated and also reaches/passes the value set for triggering the breakpoint --> either I'm doing something completly wrong or there is a problem.

I would suggest you send me a portable CCS project were you are able to place a watchpoint on a local variable. I will try this and report back.
You can use a MSP430F5529 as target MCU. Since I also own a MSP-TS430PN80USB (in addition to the MSP5529 Experimenter board) I will be able to debug it using either et eZ-FET Rev1.2 from the FR5969 Launchpad or the MSP-FET430UIF.

I will put a project together. It will be Tuesday when I can send it as I am off today through then. What I had done was to use the example you were using. However since I don't have the boosterpack it wasn't getting into that function with the min variable. So I added my own function and put a call to it near the top of main.

I will send the project along with a series of steps and explanation of what is going on with the breakpoint resources.

Regards,
John

Here is a stripped down example.  It is the blink the LED example with a global variable added and a dummy function.

Use cases:

1) Watchpoint on global variable

Launch the debug session (runs to main() automatically)

click on global, hold control, click and select Breakpoint (Code Composer Studio) -> Watchpoint with Data

enter in a value like 10

Run

The program will halt and if you enter global into the expressions view you will see that it has a value of 10

2) watchpoint on a local variable

clear the existing watchpoint

click the reset button and then the restart button which should take the program back to main()

try to set a watchpoint on local.  this will fail as the debugger is unable to determine where local is going to be located in memory

clear this failed breakpoint

use the set into button to step into func(), step to after the line that declares local

now set a watchpoint on local set to break when a value of 8 is written

run the program

it should halt when local has a value of 8

3) Breakpoints using up resources

clear breakpoints

reset, restart

set a breakpoint inside func()

run

will halt inside func()

try to set a watchpoint on local

it will complain that you have run out of resources

BlinkBPs.zip

Regards,

John