Breakpoint Woes [5.1.0]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Fri Feb 08 16:15:24 MST 2013
[FONT=Tahoma][SIZE=1]The debugger is [I]not[/I] stopping at the initial breakpoint!
excerpt from one of the console logs:
"210,337 22-break-insert --thread-group i1 -t Reset"
so gdb is apparently setting a breakpoint.

1st Aside:

What is the difference (if any) in the stop at text box of the debug configuration of:

label such as MyFunc
label with a star such as *MyFunc
address such as 0x80
address with a star *0x80

As the startup function is (always with my projects) assembler, and
thinking the debugger is confused about the arm/thumb (it's a Cortex M3 part -- 1778)
issue (but shouldn't it know that cortex is [I]never[/I] arm?) I thought to try the actual address
i.e 0x80.

I got the error popup as shown.
1) apparently I haven't defined the 'function' ([I]twice[/I]).
2) [B]SO WHAT![/B] 'Nanny' should be pensioned off and sent to live in Eastbourne.
If I want a breakpoint at an arbitrary address, I should jolly well get one!
If I don't know what I am doing, I'll soon enough find out.

If I used the 'star' alternative I think the debbuger's Nanny went away (can't quite rermember).

Back to the nub of the matter, how can I get the debugger to stop at a function label for assembler start up
(and other) code?

The function is defined as (a) global, (b) thumb func, (c) as attribute '%function'
what more should a sane man be expected to do?
Oh, and also (in this particular case) 'Reset' is the target of vector 1.

One last piece of info (in case it makes a difference); The code is already programmed to flash
(at 0x0 in this case) and the debug configuration set to [I]not[/I] load.

Bewildered, Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Feb 11 13:22:09 MST 2013
Who knows? You seem to be doing a lot of non-standard things, so you could well have made a number of mistakes. Presumably, the address that the debugger thinks is the reset vector is not the address of the reset vector in Flash - as you said, you are not programming the flash and so the address in the image (which is how the debugger knows what the addresses are) could well be out of sync with the address in flash.

The breakpoint WILL have been set. But maybe not at the address that you think. You can hit Pause button in the debugger to find out where the PC actually is. Perhaps it has vectored off to a fault handler. (see below)

To find out the address used, use the GDB console.
1. info break - will list the breakpoints
2. info func Reset - will tell you the address of the Reset function

You should also dump memory at zero to see where the Reset vector actually is.

The other thing is if you have got you vector table setup wrong. Don't forget that address 0x0 is the initial value for the SP and address 0x4 is the initial PC value. If you have these the wrong way around you can vector off into a Fault handler.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Mon Feb 11 12:33:28 MST 2013
It might not help the OP, but thank you for the clarification.

According to my (possibly too simplicistic) model of a breakpoint,
it always boils down to an address like this:
[B][FONT=Courier New][COLOR=Blue]if <current_instruction_fetch_address> == <breakpoint_address>
then stop[/COLOR]

[/FONT][/B]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Mon Feb 11 12:29:23 MST 2013
[FONT=Tahoma][SIZE=1]

Quote: CodeRedSupport
If the breakpoint is not being hit, it is because that code is not being executed...

[/SIZE][/FONT][FONT=Tahoma][SIZE=1]

Please explain how the breakpoint can not be hit when it is the target of the reset vector.

Is there any way in the IDE to
(a) see what actual address is used for a breakpoint
(b) see if the 'stop at' bp is actually inserted (doesn't show in the bp window)

Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Feb 11 08:37:35 MST 2013
Sorry, I got this wrong. The initial breakpoint cane be specified as:

[LIST]
[*]function
[*]filename:linenum
[*]filename:function
[*]*address
[/LIST]
Thus, to set an initial breakpoint at address 0x80, enter
*0x80

Hope that clarifies

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Mon Feb 11 08:09:04 MST 2013

Quote:
The initial breakpoint must be supplied as a function name or a label. Not an address, not a pointer dereference, not a symbol...

Just for clarity - where does this requirement come from ?

I would bet it comes from the IDE, or am I wrong here ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Feb 11 02:20:54 MST 2013
If the breakpoint is not being hit, it is because that code is not being executed...

The initial breakpoint must be supplied as a function name or a label. Not an address, not a pointer dereference, not a symbol...

Suggest you:
1. try using a simple 'hello world' example on your hardware (using one of our wizards). Set the initial breakpoint on ResetISR. If that works, your problem is something to do with the way you have setup your project or defined your code.
2. if (1) does not work, try your project on known working hardware (i.e. an LPCXpresso board)

I define assembler start symbol like this:

       .global _start
       .func   _start
_start:
blah...

...and using "_start" as the initial breakpoint works.