understanding STEP behaviour

[lpcware]

Content originally posted in LPCWare by caprock on Sun Apr 18 15:37:16 MST 2010
While working with the very basic Blinky process (1343), it seems as though the breakpoints are not 'sticky. What this means is that a set breakpoint will stop only one time even while the BP shows enabled.

For example, if I set a BP on the gpio that turns the led on, I get the break for the first time thru but no others; the code continues to blink.

If I then break into the code and do a 'Run To' the process fails with an exception.

I have tried this with three different programs, blinky, systick & timer32 and all seem to have the same behaviour.

Perhaps I am misunderstanding Breakpoints: are they supposed to be sticky (re-programmed for each Run condition)?

Is there an Action that needs to be set to re-enable the bp?

[lpcware]

Content originally posted in LPCWare by caprock on Mon Apr 19 10:47:19 MST 2010
With -O0 as no optimization, both breakpoints [B]are in fact, being executed[/B]. I had failed to note the timer_0_counter values.

While I still have questions about this change of optimization from -O1 to -O0, perhaps more reading will provide answers.

Thanks for all the help.

[lpcware]

Content originally posted in LPCWare by caprock on Mon Apr 19 10:14:08 MST 2010
The settings are the standard blinky debug from the sample zip file. There are no changes to any code or settings.

Within main, I am setting the bp on both GPIOSetValue procs for led on and off. These are at lines 90 & 94 and are the only path to change the led states. . I have even tried setting bp's on two assembly inst within line 90 (bp at 0x1bc & 0x1c0)

[SIZE=2][LEFT][/SIZE][SIZE=2][COLOR=#3f7f5f][SIZE=2][COLOR=#3f7f5f]/* I/O configuration and LED setting pending. */[/LEFT]
[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2][LEFT][/SIZE][B][SIZE=2][COLOR=#7f0055][SIZE=2][COLOR=#7f0055]if[/B][/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] ( (timer16_0_counter > 0) && (timer16_0_counter <= 200) )
{
[I][B]GPIOSetValue( LED_PORT, LED_BIT, LED_OFF );  <== line 90 BP [/B][/I]
}
[/SIZE][B][SIZE=2][COLOR=#7f0055][SIZE=2][COLOR=#7f0055]if[/B][/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] ( (timer16_0_counter > 200) && (timer16_0_counter <= 400) )
{
[I][B]GPIOSetValue( LED_PORT, LED_BIT, LED_ON ); <== line 94 BP [/B][/I]
}
[/SIZE][B][SIZE=2][COLOR=#7f0055][SIZE=2][COLOR=#7f0055]else[/B][/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] [/SIZE][B][SIZE=2][COLOR=#7f0055][SIZE=2][COLOR=#7f0055]if[/B][/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] ( timer16_0_counter > 400 )[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]This sample uses -O1 optimization[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]Update >> Changed the optimizations to -O0 and now stepping works partially!!![/SIZE]
[SIZE=2]http://lpcxpresso.code-red-tech.com/LPCXpresso/node/26[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]With -O0 if I again leave bp at l90 & 94, only one line bp remains active. In other words, I would assume that bp would break at line 90 then 94 then 90... but does not. If I disable 90 & enable 94, I get the 94; if I disable 94 & enable 90, I get 90.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]At this point I cannot understand the expected behaviours.[/SIZE]
[SIZE=2] [/LEFT]
[/SIZE]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 19 09:32:10 MST 2010
I presume you are debugging a Debug build rather than Release? Can you confirm what level of optimisation the Debug build is using?

The behaviour you are seeing sounds like it may well be being caused by the breakpoint you are setting being set on an initialisation instruction that is only executed the first time through the loop. You ought to be able to confirm this by looking at the disassembly view...

http://lpcxpresso.code-red-tech.com/LPCXpresso/node/28
[Login required]

There is more information on compiler optimisation and debugging that may be of interest at:

http://lpcxpresso.code-red-tech.com/LPCXpresso/node/26

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 19 09:27:04 MST 2010
One other thing - where are you setting the breakpoint? Can you reproduce on blinky and tell me exactly what you are doing (build settings, the statement/instruction you are setting the breakpoint on etc).

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 19 09:25:17 MST 2010
I don't understand the question - what do you mean by 'debug control code'?

Have you tried using a new (short!) USB cable?

[lpcware]

Content originally posted in LPCWare by caprock on Mon Apr 19 09:08:01 MST 2010
To recap - lpc1343, code red v3.3.4 & v3.2.3:
1) when a BP is set, it is entered only once
2) changing the bp state to disabled : resume : stop : enable : resume - bp does not stop
3) Restart stops at the bp but again only once.

Since you have confirmed that the bp should re-occur, and that no additional bp property settings are needed, then perhaps the board itself is the problem. With the LPC3154 providing the usb debug interface, is it possible to re-flash the debug control code?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 19 00:14:46 MST 2010
Hi,

To answer your question: Once a breakpoint is set, it remains set until you clear it.

I am not clear whether you resolved you issue, or not. The USB spec states
"the USB  specification limits the length of a cable between full speed devices to  5 meters (a little under 16 feet 5 inches). For a low speed device the  limit is 3 meters (9 feet 10 inches)"
This will be further affected by having a connector in that middle, so I can imagine that is what is causing your problem. If the debug driver is unable to properly communicate with the target, that can cause all sorts of issues.

[lpcware]

Content originally posted in LPCWare by micrio on Sun Apr 18 18:33:06 MST 2010
Another thing that I suspect was that I had a long USB cable. I had a 10 foot extension cable on my standard 3 foot cable. I can's say for sure because I still had problems when I shortened the cable. I also have had GDB crash for unexplained reasons. I still have not resolved these issues.

[lpcware]

Content originally posted in LPCWare by caprock on Sun Apr 18 16:24:36 MST 2010
LCPXpresso 1343 board
Also fails with the EA Baseboard attached

[lpcware]

Content originally posted in LPCWare by micrio on Sun Apr 18 15:53:37 MST 2010
Are your using an LPCXpresso board? I am using a board of my own design and I have weird non-reproducable problems with breakpoints. My code seems to download properly. However I can run the same code on the LPCXpresso board and breakpoints work perfectly. I believe that there is a nosie problem on my board. I am going for a re-spin.

[lpcware]

Content originally posted in LPCWare by caprock on Sun Apr 18 15:45:14 MST 2010
Yes it is.
Works only once.

[lpcware]

Content originally posted in LPCWare by micrio on Sun Apr 18 15:42:39 MST 2010
Is the breakpoint listed and enabled in the Breakpoint panel? That is the panel on the lower left by default and it has a Breakpoint tab.