CodeRed: Another Bug in LPCXpresso Debugger

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Mon Jan 21 07:04:23 MST 2013
[FONT=Tahoma][SIZE=1]This bug (LPCXpresso 4.3.0 -- but I strongly suspect that it migrated to v5) has finally driven me to post as it is so very very annoying.

It concerns 'run to line' [I am currently using assembler not "C" and I 'load' to SRAM for testing ideas; however I think it is inherent in the debug interface itself]

It seems that when run to line is selected, the debugger sets a breakpoint at the location of the link register as well as the target location -- WHY?! for God's sake! :eek:

[I have confirmed this by setting lr to various values and seeing that same value in the error message. And why TWO error messages for the same condition?]

After reset, lr is FFFFFFFF, in handlers FFFFFFFF1/FFFFFFF9/FFFFFFFD, after an IAP call, somewhere in BootROM [Why don't you let me set a BP in BootROM if I want to anyway]. :eek:

Run to (as opposed to step out) should only be setting a BP at the target location; if you must also set a BP at lr, you should handle these special cases properly.

Also, is there any way to force a hardware break point for code in ram rather than using the BKPT mechanism?

Finally, can you add 'Move to Line' to the list of user customiseable keys.

Regards, Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed Jan 23 12:44:15 MST 2013

Quote: MikeSimmonds
I hope that I never need to revist this disgusting hackery again.

you are still talking about your own code?
Each new project will give you another of those things that are fun to figure out how to solve it. This is called "learning".
The day I'll stop learning is the day I died ...

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Wed Jan 23 09:56:36 MST 2013
[FONT=Tahoma][SIZE=2]Hi Rob, Thanks for the idea. However, I hope that I never need to revist this disgusting hackery again.

Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Tue Jan 22 15:18:00 MST 2013
Mike,

There is still a way to dbug this.
First set a breakpoint on the jump instruction in flash and then set the brreakpoint in RAM.
That way you are sure the software breakpoint is not overwritten by your code.

I agree this is not the most optimal but it works.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Tue Jan 22 09:56:45 MST 2013
[FONT=Tahoma][SIZE=1]I wanted a h/w BP in ram for just one reason.

My 1st stage boot loader runs (initially) in flash, but soon copies itself (identically) to SRAM, then jumps to the next statement but in ram space.

I wanted a BP after the jump, but as the debugger thinks it is running in ram (a nasty hack story:eek:) it uses BKPT.
However, the copy overwrites the soft BP with the original code.

Water under the bridge now -- it's working. So unless I need to revisit the code, the question is moot.

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Tue Jan 22 09:47:16 MST 2013
[FONT=Tahoma][SIZE=1]

Quote: CodeRedSupport
You are wrong. LPCXpresso v5 does not behave this way, and behaves as I think you expect.

My appologies (it always goes wrong when one assumes).:o

I tried 5(00) and ran into show stopping issues (couldn't start some debug component). A dialog to select which debugger (I maybe remembering wrong) was baffling (i.e. confusing++) with several options in a drop down, but no clue or explanation as to what each was for or did).
I couldn't get the debugger going at all.

As time was critcal (when is it not), I reverted to 4.3.

Seeing the traffic in the forum and the multiple bug fix releases, I felt that 5 is (was?) not stable enough for production development; at least for me.

I am writing support code in assembler (makefile project), don't like (and don't use) CMSIS. I haven't got as far as any "C" user code stuff yet; perhaps I find more odd corners in the debugger than others.

As soon as I can get a day free (even weekends are for work at the moment), I'll load 5.14 and have another go at debugg the project.

I hope that there are not too many menu/keyboard/toolbar/layout changes to have to learn. :)

BTW, was my analysis of the v4 run to mechanism broadly correct?

I believe the 4.3 still has a bug. However, since the 5 release, I supose that I cannot expect any updates to 4.
[I sympathise with the commercial pressures.]

Cheers, Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Tue Jan 22 08:55:38 MST 2013

Quote: CodeRedSupport
To set a hardware breakpoint, using GDB, just use
hbreak *<address>
No need to go fiddling with DWT - that is what the debug driver is for!

I guess the remark refers to this:

Quote: Brutte
However, if you would like to use hardware breakpoint explicitly (for example to match on an op-code within range, like flash page, etc)

??
Well then - your hint does not set a breakpoint on a range but at specific address, it seems.
The hbreak *<address> gives nothing more than asm("0xbe13") within scope of the topic (SRAM breakpoints) so I wonder why would one use your hint in RAM when you just need a mouse click in IDE to set 0xbe13??

What I meant in a previous post is that if one needs a [B]non-trivial[/B] use of DWT or FPB (because of their much more sophisticated functionality than dumb 0xbe13), for example when you need to break on whole range of consecutive addresses or break on match of specific data, etc., then it is also doable (in RAM, wherever), but you need to configure mentioned hardware resources somehow.
AFAIK current GDB does not support whole DWT and FPB functionality except for the basic "bkpt xy" (for ARMv7, I didn't test ARMv6).

If you know how to set an instruction fetch breakpoint [B]on range of addresses[/B] (lets say 1k space) via GDB for example or if there is a tutorial showing that then please give a hint.
You can easily achieve most sophisticated breakpoints by configuring DWT (with core at run-time or EmbSysRegView or "via GDB scripts, accessing DWT", whatever).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Jan 22 06:52:35 MST 2013
To set a hardware breakpoint, using GDB, just use
hbreak *<address>
No need to go fiddling with DWT - that is what the debug driver is for!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Tue Jan 22 06:45:54 MST 2013

Quote: MikeSimmonds
[FONT=Tahoma][SIZE=1] Also, is there any way to force a hardware break point for code in ram rather than using the BKPT mechanism? [/SIZE][/FONT]

What do you mean "by hardware breakpoint"? You mean DWT, FPB or asm("bkpt 0x13")?
I can confirm what CR Support says - LPCXpresso b275 IDE + LPC1769 uses asm("0xBE13") for program breakpoints (instruction fetches) from RAM and does not use DWT or FPB resources at all (except for default CYCCNT, etc). This behaviour is transparent for the user - you just set and remove these same as regular breakpoints in Flash. It is very convenient as you can set as many breakpoints as you wish :cool:
However, if you would like to use hardware breakpoint explicitly (for example to match on an op-code within range, like flash page, etc) then you need to configure DWT manually (no GUI provided). Unfortunately "sparse register bushes" of LPCXpresso will not help you with that because AFAIK the DWT is still hidden in LPCXpresso - you need EmbSysRegView for that (works fine within IDE).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Jan 22 06:15:46 MST 2013

Quote: MikeSimmonds
[FONT=Tahoma][SIZE=1]This bug (LPCXpresso 4.3.0 -- but I strongly suspect that it migrated to v5) has finally driven me to post as it is so very very annoying.

[/SIZE][/FONT]

You are wrong. LPCXpresso v5 does not behave this way, and behaves as I think you expect.

Quote: MikeSimmonds

[FONT=Tahoma][SIZE=1]Also, is there any way to force a hardware break point for code in ram rather than using the BKPT mechanism?
[/SIZE][/FONT]

Hardware breakpoints are a scarce resource and so are used sparingly. GDB decides which type to use based on the attribute of the memory - Flash uses h/w breakpoints, and RAM uses s/w breakpoints. By using GDB directly you can specifically set h/w or s/w breakpoints, but we do not provide a way to do this through the GUI - use the GDB console if you want to do this yourself.