Restore Debug Session Views

[lpcware]

Content originally posted in LPCWare by cwpjr on Wed Feb 13 18:10:37 MST 2013
I searched for the title string in the forum. I didn't see a result in the 1rst 2 pages that tells me about this scenario:

I quit the debugger, where I had multiple views set up, such as register tab EXPANDED in one view, several memory tasks, some with selected RENDERINGS , etc.

When I relaunch the debugger I have to manually reconstruct every view.

I have tried saving views, projects, workspace etc and restoring these saved items I still have to reconstruct all my views.

Is there a solution?

Thank you, Clyde

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Feb 15 22:17:48 MST 2013

---

Quote: MikeSimmonds
[FONT=Tahoma][SIZE=2]
PS: One last question; if I code a bkpt instruction, will the debugger cut in and then
behave as if a breakpoint was hit?
[/SIZE][/FONT]

---

The debugger should display the context where execution halted at the location of the BKPT, and report an "Unknown" breakpoint.

Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Feb 15 07:55:48 MST 2013
[FONT=Tahoma][SIZE=2]OK, It seems like I am on my own on this one, but to satisfy your curiosity ...

I have a 4K boot loader which, depending on dip-switch settings 'launches' to one
of the modules (plural) loaded farther on in flash space. It can also burn flash with
my post processed elf image 'modules' (a separate switch setting).
This is entirely self contained, working, and debugged.

The 'modules' have had the elf post processed to add a custom header containing a
CRC-32 checksum, a start address 'vector' and a table of relocation/bss clear items.
They do not have the usual vector table at the base of the code image.
[As an aside, my startup code for modules as well as relocation of data and SRAM code
and clearing bss areas in on chip sram, off chip sram and off chip dynamic ram will
construct a dymanic vector table in on-chip sram (@ 10000000)]
The Boot block uses this header to validate the code module and give it control.

So I can't let the debugger load the elf's.

My debug cycle is to edit/build a module, post process, burn to flash (via the Primary
Boot Block) change the switches to 'go X' and then invoke the LPCXpresso debug.

What I wanted to happen is that the debugger resets the CPU (without loading anything)
sets a breakpoint in the module (e.g. somewhere in flash sector 12 for example) and
runs from Vector[1] in flash (@00000004). I.e the Primary Boot. This would jump to the
module start entry and hit the breakpoint from the 'Stop At' dialog.

I finally see from your previous post, that that is not how you have written the dubugger.
Although it could do this, it dosen't. This was never spelt out (at least where I could see).

So as a work round, I will put a call to my Init function to a 'pause-me'  routine (if a
certain dip switch is on) which will just branch to self.
I can then break in (suspend), move the pc past the branch to self on to the function
return, manually add my desired bp, and resume.

The difference between how I thought the debugger functioned and how it actually
does was frustrating because the consequences of 'don't load' are not specified.

Still [I]now[/I] I know and can compensate.

Similarly, it seems that the 'reset' button does, in fact, [I]not[/I] do a chip reset. Interpolation
of events would imply that it sets the stack pointer from vector[0] [I]from the relocated
vector table[/I] and presumably would go on to set the PC to vector[1]. (I am getting
a hard fault due to rubbish at that location.)

I was expecting a proper reset, whereby the flash @ zero table would be re-instated
and things would proceed from there.

Again, now that I know, I can put a workround into place.

There is still an ocaisional issue with 'move to line' positioning at the following code address (i.e. +4 from where it should be). Assembler, not C so optimisation is not
to blame. (At least once this happend with a breakpoint, instead of the value of the
label, got label+4.) That one is still open for me.

Cheers, Mike

PS: One last question; if I code a bkpt instruction, will the debugger cut in and then
behave as if a breakpoint was hit?

[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Feb 15 06:13:45 MST 2013
No. You have not explained why you are trying to do this, so I cannot suggest anything that might help. Please explain exactly what you are trying to do and why. We might then be able to help.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Feb 15 05:26:05 MST 2013
[FONT=Garamond][SIZE=2]So there is not a combination of options to (a) 'not load' and (b) reset the processor?
[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Feb 15 05:18:08 MST 2013
I think you said in an earlier thread that you were not loading the application. In that case, you are connecting to a running system. i.e. it is already running and therefore it will not stop as you have already gone past any breakpoint at startup.

So, why are you trying to do this?

Unless you can provide an example that we can try here, we are not going to be able to help with your obscure setup.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Feb 15 05:11:59 MST 2013
[FONT=Arial][SIZE=2]Firstly, thanks for the explanation and hints for future releases.

[/SIZE][/FONT][FONT=Arial][SIZE=2]

---

Quote:
Can you provide exact details of how you managed to collapse the debug view? We know of no circumstances where this can occur

---

Perhaps I am using the wrong terminology; I will add some pictures.
But [I]I[/I] did not collapse the debug view; this is how it presents itself.

The LPC-Link has been un-plugged and re-inserted (because of an issue
with the reset button -- see http://knowledgebase.nxp.com/showthread.php?t=4152
133 views, [I]no[/I] replies)

I start the IDE (5.1.0) from the desktop shortcut.
I click the toolbar debug icon.
I make sure that Stop on Startup at is set to "AppInit" (a C function) and click Debug.

The debugger does its stuff, but does not stop at "AppInit"

[In your reply in another thread, I read the sub-text as you didn't want (have time) to
resolve the issue because my firmware is not bog-standard "C" and CMIS -- I get it
that this is a free (as in beer) product and you don't want to chase obscure issues
that only seem affect one of your users.]

See "DebugRun1" (Note the icons are greyed out).

I then expand the tree and select the top stack frame; the icons are now available
and I can suspend the code. See "DebugRun-2".

Note, in the call hierarchy, that execution has passed through "AppInit" which is
where I asked the debugger to stop.

Regards, Mike






[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Feb 15 04:13:42 MST 2013

---

Quote:

Also it defaulted to 'traditional' so I didn't even notice there might be an issue.
Now it defaults to hex and I have to close and select 'trad'.
I couldn't find any where to set a default back to traditional.
Was there a sensible reason for this, or was it change for changes sake. Or did a lot of people ask for it?
Regardless, it is a new hoop we all have to jump through if we don't like 'hex' view.

---

We are working on addressing this issue

---

Quote:

Also, the call hierarchy (debug pane) is always closed (surely most would want it open -- another hoop)
The worst thing about this is that halt/step/etc. are greyed out until you expand (and select) a call frame. When does it ever make sense to disable the controls if you are in debug mode? (Also, I think v4 remembered the 'instruction step' mode between sessions.)

---

Can you provide exact details of how you managed to collapse the debug view? We know of no circumstances where this can occur

---

Quote:

The third anoying hoop is the registers view. First it has aquired a totaly pointless tree structure, and again, is ALWAYS closed.
Personnaly, I can not think of an example where you select the registers, but don't actually want to view them.

---

The next release will expand the Registers and add some other detailed improvements to the view

---

Quote:


I want the "Core Registers" from v4 back -- pleeeeeese.

Don't get me wrong, 5.1.0 is much more stable than 4.3 was, but the price seems to be a fairly big backward step in useability. It is hard to unlearn habits -- and I cant see any benefit to justify the changes. (or reason for them).

---

The reason is that the debugger is a complete re-write compared with RS4. This has been done so that we can provide some new functionality in a future release. Some of the features you request are being worked on and improvements are being made release-to-release.

[lpcware]

Content originally posted in LPCWare by cwpjr on Thu Feb 14 18:53:55 MST 2013
That is all. Happy Valentine.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Thu Feb 14 09:42:36 MST 2013
[FONT=Trebuchet MS][SIZE=2]

---

Quote: cwpjr
I searched for the title string in the forum. I  didn't see a result in the 1rst 2 pages that tells me about this  scenario:

I quit the debugger, where I had multiple views set up, such as register  tab EXPANDED in one view, several memory tasks, some with selected  RENDERINGS , etc.

When I relaunch the debugger I have to manually reconstruct every view.

I have tried saving views, projects, workspace etc and restoring these saved items I still have to reconstruct all my views.

Is there a solution?

Thank you, Clyde

---

[/SIZE][/FONT]      [FONT=Trebuchet MS][SIZE=1][SIZE=2]I second this.

V4 kept the memory views, between sessions even, (but didn't remember cell size or columns).
Also it defaulted to 'traditional' so I didn't even notice there might be an issue.
Now it defaults to hex and I have to close and select 'trad'.
I couldn't find any where to set a default back to traditional.
Was there a sensible reason for this, or was it change for changes sake. Or did a lot of people ask for it?
Regardless, it is a new hoop we all have to jump through if we don't like 'hex' view.

Also, the call hierarchy (debug pane) is always closed (surely most would want it open -- another hoop)
The worst thing about this is that halt/step/etc. are greyed out until you expand (and select) a call frame. When does it ever make sense to disable the controls if you are in debug mode? (Also, I think v4 remembered the 'instruction step' mode between sessions.)

The third anoying hoop is the registers view. First it has aquired a totaly pointless tree structure,  and again, is ALWAYS closed.
Personnaly, I can not think of an example where you select the registers, but don't actually want to view them.
I want the "Core Registers" from v4 back -- pleeeeeese.

Don't get me wrong, 5.1.0 is [I]much[/I] more stable than 4.3 was, but the price seems to be a fairly big backward step in useability. It is hard to unlearn habits -- and I cant see any benefit to justify the changes. (or reason for them).

Still, for many reasons, I will stick with 5. Thanks for the release.
Perhaps you could treat my comments/comparisons as a wish list.

Mike

[/SIZE][/SIZE][/FONT]