Lonh delay starting debugger

[lpcware]

Content originally posted in LPCWare by ronkrem on Fri Jun 21 00:47:28 MST 2013
I am debugging an LPC11U35FBD48/401 with the standard 10-pin LPC-Link using the four pins RESET, MOSI0, SCK0 and SWDIO. Apart from the USB pins and PIO0_3 (USB_VBUS), every other pin is in use as either an input or output.

When the xpresso debugger is started it hangs for 20 or so seconds at the ResetISR() function in the startup module before continuing to the normal debugger point start in main().

I suspect some pin associated with the serial link is being held in an unexpected state by my circuit. Can anyone suggest if this is so and which pin it would be?

Regards
Ron

[lpcware]

Content originally posted in LPCWare by ronkrem on Wed Jun 26 04:39:58 MST 2013
Here is the final entry in this discussion. I happened to click on the Breakpoints tab in the Debug perspective, and there was an array called eeprom[] with every entry ticked. Unfortunately I cleared them with the "delete all" before examining how many there were, but that was the cause of the problem, presumably the debugger was trying to read the state of each and every entry before proceeding. My code does not have an array in it with that name, so I have no idea where it came from and how every entry was flagged as a breakpoint. Something to watch if you use the LPC eeprom.
Ron

[lpcware]

Content originally posted in LPCWare by ronkrem on Tue Jun 25 21:28:09 MST 2013
Ok. I found the problem. In this particular board, I am using the eeprom in the LPC11U35 to store an array of 1670 bytes. In V5 I can access the gdb traces in the console, and these are showing repeated attempts to read eeprom addresses. The text is scrolling, but the message loks like:
xxx-xxx xxx-break-insert --thread-group i1 <then the repeated line # in my eeprom.c module>.
Removing the eeprom.c file and commenting any accesses restores the debugger to its usual fast startup.
So it is associated withh eeprom access, but as the program has not yet started, I am at a loss to know why this occurs.
Ron

[lpcware]

Content originally posted in LPCWare by ronkrem on Tue Jun 25 20:39:14 MST 2013
You tell me. I only used the site's tools and it reduced the size of my jpeg to be under its limit of 19.5 Kb. My original intention was to simply attach the 251Kb pdf.
Regards, Ron

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Tue Jun 25 08:34:08 MST 2013

---

Quote: ronkrem
Yes, well your site only allows tiny images.

---

Really? What did this post do then?
http://knowledgebase.nxp.com/showpost.php?p=30329&postcount=13

[lpcware]

Content originally posted in LPCWare by ronkrem on Tue Jun 25 08:11:44 MST 2013
Yes, well your site only allows tiny images. Here is a link: www.kremford.com.au/KF095-1.pdf .
The boot address and the ISP was a clue as the pin has no direct pullup as you can see. However the default PIO0_1 has the internal pullup on, and checking with a meter shows the pin at 3.3V throughout startup. Using a scope shows no AC either. Any other way it could end up looking at the boot address? Remember it eventually does start in the standard main().
Ron

[lpcware]

Content originally posted in LPCWare by R2D2 on Tue Jun 25 04:07:37 MST 2013
Your attached image is very small, so I can just guess.

Address  0x1fff0420 is in Boot ROM, so the first thing to check is your ISP pin :)

[lpcware]

Content originally posted in LPCWare by ronkrem on Tue Jun 25 03:05:50 MST 2013
Thanks for that suggestion and I have installed 5. All works much the same and on other boards using various LPC chips the debugger startup is very quick. However, on this particular board where most all pins are in use, the new version takes even longer to arrive in main (upwards of two minutes!). The difference is that for the very first debug sesion it did not display the ResetISR function as for 4, but put up a window it calls 0x1fff0420 with the message "no source". In subsequent sessions it now pops up a random C file from the project which it displays for several minutes before showing the main() function and debugging can then begin as normal.

I suspect it is a pin I have used incorrectly. To help I have attached the circuit diagram of the processor on this particular board with the pin IO directions marked.

Regards, Ron

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 24 00:34:01 MST 2013
I see you are using LPCXpresso v4. The debug startup time was significantly improved in v5. If this is a significant problem for you, I suggest you consider upgrading to v5.

http://support.code-red-tech.com/CodeRedWiki/DebugEmulatorSelectionDialog

[lpcware]

Content originally posted in LPCWare by ronkrem on Sat Jun 22 01:53:51 MST 2013
Here are the two console log views available while the debugger is sitting at the ResetISR() function:

[LEFT][SIZE=2]LPCXpresso Debug Driver v4.0 (May 21 2012 21:42:54)[/SIZE]
[SIZE=2]Looked for chip XML file in C:/nxp/LPCXpresso_4.2.3_292/lpcxpresso/bin/LPC11U35/401.xml[/SIZE]
[SIZE=2]Looked for vendor directory XML file in C:/nxp/LPCXpresso_4.2.3_292/lpcxpresso/bin/nxp_directory.xml[/SIZE]
[SIZE=2]Found generic directory XML file in C:/nxp/LPCXpresso_4.2.3_292/lpcxpresso/bin/crt_directory.xml[/SIZE]
[SIZE=2]Emu(0): Conn&Reset. DpID: BB11477. Info: T1S6RGRIA[/SIZE]
[SIZE=2]SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.[/SIZE]
[SIZE=2]Packet delay: 0 Poll delay: 0.[/SIZE]
[SIZE=2]NXP: LPC11U35/401 Part ID: 0x0001BC40[/SIZE]
[SIZE=2]Connected: was_reset=false. was_stopped=false[/SIZE]
[SIZE=2]v Registered license, download limit of 128K[/SIZE]
[SIZE=2]Writing 21944 bytes to 0000 in Flash (assumed clock: 48.0MHz)[/SIZE]
[SIZE=2]Verified-same page 0-5 with 21944 bytes in 3542msec[/SIZE]
[SIZE=2]Flash write Done[/SIZE]
[SIZE=2]nSRST assert (if available)[/SIZE][/LEFT]
[SIZE=2]Executing in user flash.[/SIZE]

[SIZE=2]and:[/SIZE]

[LEFT][SIZE=2][SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]set remotetimeout 60000[/COLOR][/SIZE][/COLOR][/SIZE][/SIZE]
[SIZE=2][SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]info program[/COLOR][/SIZE][/COLOR][/SIZE][/SIZE][SIZE=2]
[SIZE=2]Debugging a target over a serial line.[/SIZE]
[SIZE=2]Program stopped at 0xc44.[/SIZE]
[SIZE=2]Type "info stack" or "info registers" for more information.[/SIZE]
[SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]set mem inaccessible-by-default off[/COLOR][/SIZE][/COLOR][/SIZE]
[SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]mon ondisconnect cont[/COLOR][/SIZE][/COLOR][/SIZE]
[SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]set arm force-mode thumb[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2][COLOR=#ff0000][/LEFT]
[/COLOR][/SIZE]
The LED1 on the LPC-Link is dim but flashing. It is 38 seconds from the time the "set remotetimeout" message appears until the debug display changes to the main() function. The program sizes reported are:

21936, 8, 3528, 25472

Do you still consider this delay is the flash being programmed?

Regards
Ron

[/SIZE]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Jun 21 06:40:29 MST 2013
If you switch to the debug log in the console view, you will probably find that the debug connection and flash programming is taking place during this time - the editor view is just waiting for this to complete before it gets refreshed.

Regards,
CodeRedSupport