How to Debug with no executable and no sources

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Mar 09 14:41:51 MST 2015
I want to start a debug session on  a board.
I have no source, no elf (axf) files.
I want to select the processor type (4370) and to select SWD mode.
I have IDE version 7 and a LPCLink-2 probe.

I can setup a NXP MCU debug launch (with the application left blank)
And setup the options. Mainly SWD, AttachOnly:True: LoadImage:False,
ResetScript:blank (I do not want to reset!)
And no RedTrace or semihosting support thank you so very much!

However, the "Debug" button is greyed out and I can't even try to start a debug session.

I then tried "Attach to Application"
Firstly, there seems to be no way to specify the NXP MCU -- other than having it set in the project properties*.
Second with the debugger tab defaults of gdb clicking the "Debug" button Failed with the error "gdb --version".

I specified a path to <install dir>/tools/arm-none-eabi-gdb.exe, then when I click the "Debug" button
I get a list of processes running on the host PC [Win7-64]. Not what I need at all.

So, I am stuck.

Please NXP (or anyone else) post a FAQ about how to debug a board (attach only/no load) when there is no
source or executable available.
I am quite happy to only see the disassembly. But I do want to open 4370 specific peripheral views.

* By the way I could not setup a new completely empty project folder. I had to put a dummy empty file there
(which I called main.c).

Regards, Mike

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Mar 10 14:25:55 MST 2015
Thanks. I will look into all you say.

Cheers, Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 10 12:03:47 MST 2015

My first thought is your linker script is inadequate. By providing almost no guidance to the linker, you're begging to be victimized by default tool behavior. I recommend you use the managed linker scripts, and the LPC43xx startup code provided by LPCXpresso. Review the LPC4330 example projects.

A DFU load would setup the M4MEMMAP. And, the debugger bypasses the bootloader by loading directly to RAM so there's no reason to change the vector checksum. I recommend you add the reset script LPC18LPC43RamReset.scp to your debug configuration.

LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Mar 10 10:38:48 MST 2015
Sorry, I forgot to say thanks.

I had just about come to a similar conclusion: Create a dummy executable and debug with attach only.
Essentially, the dummy code is ignored.

Note: I have been using 1778 for about 3+ years, but I am new to the flashless 4370.

When I actually load the dummy code (via the debugger), I am confused about the MEM4MAP setting.

@=======================================================================!
@ DUMMY.SCopyright (c) Waived.10-08-12!
@=======================================================================!

@ vim: set ts=8 sw=8:@ [tabs:8]

.file"Dummy.s"
.syntax unified
.thumb

.macrofn n
.type\n, %function
.func\n
.thumbFunc
\n:
.endm

.macrofe n
.endfunc
.size\n, .-\n
.align1,0
.endm

@-----------------------------------------------------------------------!
@ Publics!
@-----------------------------------------------------------------------!

.globalStartHere

@-----------------------------------------------------------------------!
@ Constants and Equates!
@-----------------------------------------------------------------------!

@-----------------------------------------------------------------------!
@ CODE!
@-----------------------------------------------------------------------!
.text
.align 4,0

Vectors:

.word0x10000800@ stack
.wordStartHere@ reset
.wordStartHere@ NMI
.wordStartHere@ hard fault
.word0@ dummy
.word0@ dummy
.word0@ dummy
.word0@ dummy

@-----------------------------------------------------------------------!
@ Initialise Clock etc. Copy Code & Data, Zap bss!
@-----------------------------------------------------------------------!

fn StartHere

b.@ spin forever

fe StartHere

@-----------------------------------------------------------------------!
@ LDR pool!
@-----------------------------------------------------------------------!
.align 2,0xFF

Pool: .pool@ LDR pool

@------------------------------------------------------------------------
.align4,0xFF
@========================================================================

I don't normally use the managed linker scripts; it wasn't working for me and I could not be bothered to find out why.
So I used this script (minimal as you can see).

ENTRY(StartHere)


SECTIONS
{
.text 0:
{
*(.text)
}

}

My question is: The debugger loaded the code to memory @ 0x10000000, but did not change the MEM4MAP register
away from the default of [boot rom].

Why, the exectable shows 'reset' at 0x21 (and not 0x10000021) if you disassemble.

Would a genuine dfu load set memmap correctly?

Also, looking at the code bytes in the memory viewer, shows that the 'vector checksum'
was not changed from zero.

Regards, Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 09 18:05:39 MST 2015

You are close to working.

1. Create a dummy project, with an empty main(). Sounds like you've done this already. Compile the project with a debug setting of "None".

2. Create a Debug Configuration for the above project. Set "Attach" to true. You don't need to disable the "Load image" because the debugger will ignore the image.

3. Attach a debug session to the running target.

4. Hit the pause key. There will be no debug information, so you'll get a message similar to:

"No source available for "0x????"

The address in the message is whatever PC you've halted at.

Enjoy the no symbols experience.

LPCXpresso Support

PS  After saving the Dummy Debug Configuration, open it back up and check your settings.