Cannot debug

[lpcware]

Content originally posted in LPCWare by stl on Sun Apr 03 21:02:03 MST 2011
I'm using the LPC-Link with a LPC113/301 target and have a problem debugging my code.

Basically once I start debug, it does not stop at any breakpoints. Even if I set to stop on main() at startup, it just keeps running without stop. Note I do not know whether the firmware is actually running, all I know is in the "Debug" panel, under "MCU GDB Debugger" it shows "Thread [1] (Running)", and it does not stop anywhere in the source as I would expect.

I'm pretty sure the debug connection itself is working, because I am able to program the flash. I've also tried some of the diagnostics suggested in another post (log attached), and as far as I can tell nothing is amiss.

Looking at the console output, the most suspicious looking line is this:
GDB trying to set entry point of 0x0118, but correct entry is 0x1FFF0F10

Any suggestions on why this happens?

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Apr 04 14:49:36 MST 2011

---

Quote: CodeRedSupport
...The message itself is harmless, but, as you suspect, may provide other clues.

---

Good answer.  I thought there was more of the story to be told.

Even with the message "GDB trying to set entry point of 0xxxxx, but correct entry is 0x1FFF0F10" I was able to debug my project.

I'll have to watch for the message to appear again and do some investigation at that time.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 04 14:06:19 MST 2011

---

Quote: larryvc
Hi Steve,

I've seen this as well but didn't notice any problems with debugging my project. Could this be hiding something that could cause problems or is it a harmless message?

---

To add to this discussion, the message "GDB trying to set entry point of 0x0118, but correct entry is 0x1FFF0F10" is a result of GDB attempting to set the starting PC to the location defined by the linker script ENTRY command. As Steve mentioned, the NXP parts need to complete the boot ROM calibration in order to function correctly. The debug utility (in most cases) would ignore the GDB request, since it must first ensure the boot ROM calibration can finish after the part is reset. The part vectors to user code after calibration, provided a valid application has been flashed, then runs to the first breakpoint (typically 'main').

The bad checksum reference given earlier would mean the part can never enter user code. In this case, the PC is somewhere in the boot ROM when the part enters debug halt. The message itself is harmless, but, as you suspect, may provide other clues.

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Apr 04 12:01:40 MST 2011

---

Quote: SteveClevenger
This message tells you GDB is trying to set a different entry point for your linked application, than the debugger thinks is appropriate. The 0x1FFF0F10 address is in the boot ROM, not user flash. It's not uncommon to see this...

---

I've seen this as well but didn't notice any problems with debugging my project.  Could this be hiding something that could cause problems or is it a harmless message?

[lpcware]

Content originally posted in LPCWare by SteveClevenger on Mon Apr 04 00:20:47 MST 2011

---

Quote: stl

Looking at the console output, the most suspicious looking line is this:
GDB trying to set entry point of 0x0118, but correct entry is 0x1FFF0F10

Any suggestions on why this happens?

---

This message tells you GDB is trying to set a different entry point for your linked application, than the debugger thinks is appropriate. The 0x1FFF0F10 address is in the boot ROM, not user flash. It's not uncommon to see this, but it could also mean the NXP boot ROM could not validate the application checksum. The LPCXpresso debugger calculates (and embeds) the correct checksum during flash program, so no need to do this yourself (in case you are).

Second, if you've modifed the standard entry code, be certain you do not alter the SYSMEM_REMAP setting.

Third, most of these parts rely on the boot ROM to setup calibration values, and the like. It's possible the boot ROM did not complete it's chores before the debugger took control. You can try setting the "Vector catch" option to 'True' in your Debug Configuration to see if this makes a difference, or just boot the part into the ISP before connecting. ISP details are in the User's Manual.