GDB problems

[lpcware]

Content originally posted in LPCWare by JohnR on Thu Jan 27 19:23:54 MST 2011
Hi,

When I start debugging in LPCXpresso, a  Windows error dialog box appears complaining about crt_emu_lpc11_13_nxp.exe. I can click the Don't Send button and the system continues on to open the debugger which appears to function normally. I set break points, read out variables and so on.

Today I noticed that the computer while running the debugger seems very sluggish and looking at the Windows Task Manager, crt_emu_lpc11_13_nxp.exe is taking some 80% cpu time.

The computer is a plain vanilla IBM laptop running Windows XP SP3 with 1.00GB RAM.

Is crt_emu_lpc11_13_nxp.exe usually such a resource hog? I have both v3.4 and v3.5 and both show the error message on starting the debugger.

Thanks for any help

John.

[lpcware]

Content originally posted in LPCWare by JohnR on Sat Jan 29 11:54:02 MST 2011
Thai's an amazing spread of values!

I also have used LPCXpresso on an Asus netbook and found similar results.

Well, I guess it was time to upgrade my IBM Thinkpad that is 10 years old now.

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Sat Jan 29 07:19:03 MST 2011
IBM ThinkPad Celeron 1.4 GHz 1.25 GB RAM with XP Pro Debugger (running) : 55-75% :mad:

AMD Athlon X2 6000+ 4GB RAM with Win7 /32 Pro Debugger (running) : 1- 3% :)

Asus EEEPC Atom 1.6 GHz 2GB RAM with XP Home Debugger (running) : 35-50% :eek:

[lpcware]

Content originally posted in LPCWare by JohnR on Sat Jan 29 06:43:37 MST 2011

---

Quote:
I have not seen it go as high as 70%, but it is doing something.

---

It would be interesting to know what level of CPU usage other users are experiencing?

John.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Jan 28 11:33:12 MST 2011
While your application is running, the debug driver is 'polling' the debug target to see if it has anything to do (e.g. semihosting (printf), debug break/watchpoints etc). I have not seen it go as high as 70%, but it is doing something.

[lpcware]

Content originally posted in LPCWare by JohnR on Fri Jan 28 10:17:24 MST 2011
Just while the debugger is actually running. When it is halted (but still open) the CPU usage is 0%.

John

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Jan 28 09:25:06 MST 2011
At what point is it 70-80%? When the application is running? When it has stopped? Please provide some more info so we can investigate.

[lpcware]

Content originally posted in LPCWare by JohnR on Fri Jan 28 07:21:25 MST 2011
Thanks for the reply.

I updated the dll as you suggested and rebooted.

The initial error dialog has gone but the consumption of the debugger is still 70 - 80%.

Is this normal?

John

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Jan 28 01:21:37 MST 2011
Do you have any FTDI-based USB-serial adapters, logic analyzers, or any other FTDI-based devices?

When starting a debug session, the IDE scans USB looking for debug probes to use. This includes searching for Red Probe, which uses an FTDI chip and uses FTDI drivers.
We recently found an issue where one of the FTDI DLLs we use was not updated during the install, and consequently we were calling an out-of-date DLL which caused the crash.

Look in your Windows\System32 directory for ftd2xx.dll.The version that we ship is over 200k in size and a version number of 3.1.19.0 (in Explorer, right-click, select Properties and click on the Details tab). If your version is older, you can:
- take a copy of the current version (so you can revert if any problems are found with existing apps that use the FTDI parts)
- copy the version we supply in Drivers\RedProbe+\i386 over the current version
- reboot

Now try debugging again