Slow emulator launch

[lpcware]

Content originally posted in LPCWare by briand on Sun Sep 05 12:18:09 MST 2010
I have lpcxpresso up and running and able to debug code with the lpc-link, but it takes forever (many minutes) to start each time I hit debug.  I understand it may take an extra minute or two the first time the lpc-link DFU needs to download firmware and re-initialize as an emulator, but I'm getting large delay (a minute or more) on "checking emulator" each time.  Actual debugging seems very slow too, semihosted messages print to the console at a speed that reminds me of 1200 baud modems days.  I checked USBView and noticed the lpc-link is always full speed, isn't it supposed to be high speed?  Besides the usual candidates (USB cable, different port) is there anything else I should try?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Sep 08 23:00:50 MST 2010

---

Quote: briand
Well hrm.  This seems to be coming and going.  My last reply ("it's magically fixed!") only lasted a few iterations, and now it's back to the really slow startup most of the time.  Is there any polling or waiting that might happen between the first time crt_emu_cm3_nxp is called and the second?  What I see when I hit debug:

-build finishes
-progress gets to 57% ("checking emulator")
-copy of crt_emu_cm3_nxp is idle in task manager
-a minute later (or so), 1st copy of crt_emu finally exits
-the cscript runs, new copy of crt_emu and gdb start up, upload and debug runs (looks like normal speed)

If I kill off the first copy of crt_emu during the wait time, lpcxpresso immediately takes off and does the upload, and things go well.  If I wait around, I'm stuck waiting around... any other logs or info I should be looking at?

---

The DFUAPP timeout value (see '<install>\bin\Scripts\bootLPCXpresso.cmd') may not be  appropriate for your system. This is the '/tl 250' parameter. We've also seen the occasional problem with cscript execution, particularly if you use a virus checker which logs cscript progress.

The first crt_emu_cm3_nxp task checks to see if there is an LPCXpresso to talk to. If not, it looks for the DFU device to download the firmware. This process takes some time when you first connect, but follow-on connections should be seemless.

Try this experiment.

1. Power cycle your LPCXpresso board by removing the USB cable, and reinserting it. This will boot the DFU device.
2. Manually load the probe firmware using DFUAPP.exe, and see if the connection delay is resolved when you restart the IDE. You can test with one of three probes:

LPCXpressoFS.enc (XP default probe)
LPCXpressoHS.enc
LPCXpressoWIN.enc

The latter two use USB high speed.

So, as an example, the following command would download the high speed HID probe.

C:\nxp\lpcxpresso_3.5\bin\DFUAPP.exe /f LPCXpressoHS.enc

After the LPCXpresso device is present, restart the IDE.

[lpcware]

Content originally posted in LPCWare by briand on Wed Sep 08 22:12:29 MST 2010
Well hrm.  This seems to be coming and going.  My last reply ("it's magically fixed!") only lasted a few iterations, and now it's back to the really slow startup most of the time.  Is there any polling or waiting that might happen between the first time crt_emu_cm3_nxp is called and the second?  What I see when I hit debug:

-build finishes
-progress gets to 57% ("checking emulator")
-copy of crt_emu_cm3_nxp is idle in task manager
-a minute later (or so), 1st copy of crt_emu finally exits
-the cscript runs, new copy of crt_emu and gdb start up, upload and debug runs (looks like normal speed)

If I kill off the first copy of crt_emu during the wait time, lpcxpresso immediately takes off and does the upload, and things go well.  If I wait around, I'm stuck waiting around... any other logs or info I should be looking at?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Sep 07 19:49:42 MST 2010

---

Quote: briand
Thanks for the info on firmware.  For whatever reason after the long weekend my lpc-link started working fine today.  I was ready to try switching the firmware but it comes right up and is debugging in about 12 seconds now.

Is there a particular reason not to use either of the high speed drivers on XP?

---

We've found the high speed USB performance on certain XP systems to be less reliable (i.e. "slower") than full speed USB. I'm sure there's an explainable reason for this, we just don't know what it is. Most SP3 machines are fine at high speed, however.

Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by briand on Tue Sep 07 12:14:53 MST 2010
Thanks for the info on firmware.  For whatever reason after the long weekend my lpc-link started working fine today.  I was ready to try switching the firmware but it comes right up and is debugging in about 12 seconds now.

Is there a particular reason not to use either of the high speed drivers on XP?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sun Sep 05 22:32:15 MST 2010
If Windows XP SP3 is installed on your machine, the USB full speed limited HID firmware is installed as the default LPCXpresso probe. The probe firmware itself is downloaded only when the DFU device is present. It sounds like you're using an LPCXpresso board as a standalone probe. The surgery required to sever the J4 connection to the on board NXP part can sometimes damage the probe, but it usually doesn't work at all vs. working slowly.

The firmware for three distinct probe versions are supplied with LPC-Link. These are LPCXpressoWIN.enc (High Speed WinUSB), LPCXpressoHS.enc (High Speed HID), and LPCXpressoFS.enc (Full Speed HID). The different firmware is necessary to accommodate variations in Windows OS and PC hardware still in use. The bootLPCXpresso.cmd script in the '<install>\bin\Scripts' decides which to use based on Windows version, but you can override the selection in the script to test with other probe versions. We suggest you always use a direct USB connection vs. through an external hub.

Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by briand on Sun Sep 05 13:30:55 MST 2010
Nothing about the machine is suspicious, it's a multi-ghz quad-core desktop with 4gb ram running XP32-SP3 on bare metal.

The target board is an NGX blueboard 1768.  I have some whole lpcxpresso 1343 boards though that I haven't tried it on; I'll give that a shot and report back if it's still slow there too.  I don't particularly mind the slow semihost printfs; I normally do debug logging straight through UART so as long as I can resolve the slow startup time I'll be happy.

Should USBView show lpc-link as high-speed usb?  Does the firmware get downloaded each time the emulator starts up?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sun Sep 05 12:57:34 MST 2010
Your "checking emulator" time certainly seems somewhat slow. Can you please provide some more information about your system:

- Computer age, laptop/desktop, processor, memory, OS and service pack ? And is the OS running natively or are you using a virtual machine of any form?

- What is your target? Are you just using an lpcxpresso board - if so which one? Or are you using the lpc-link to connect to your own target board, in which case can you give a few details?

With regards to semihosting, this is currently not particularly fast when using the Redlib printf library code with lpc-link. You might want to look at the "consoleprint" example which provides a means of speeding it up somewhat.

Regards,
CodeRedSupport