Yep, app is totally working and giving messages, I have tried 2 ways - to delete it and let the debugger load it, and to let it work (made it output debug string every second) and run the debugger, which says it is already loaded and no need to load again, but the result is the same. I guess if I reload the module OS it will start working for a while again.
Actually I can’t anymore even reach to this error, now it is timeouts all over the place (yet the app gets perfectly fine loaded and working on the modem). This happens now when I either load the app via debug or attach to working one:
Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Packet qSupported (supported-packets) is supported
warning: unrecognized item "timeout" in "qSupported" response
Sending packet: $?#3f...Sending packet: $?#3f...Sending packet: $?#3f...Sending packet: $?#3f...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $Hc-1#09...Sending packet: $Hc-1#09...Sending packet: $Hc-1#09...Sending packet: $Hc-1#09...Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $qC#b4...Sending packet: $qC#b4...Sending packet: $qC#b4...Sending packet: $qC#b4...Also when I press terminate arm-elf-gdb.exe crashes. Restarting dev studio does not help.
DS has an intermittent bug where it doesn’t start the application correctly (AT+WOPEN=1) when using the Run or Debug facility. You should make sure it is correctly started (even by using the status view buttons) before debugging it.
However, if you confirm that you have the issue even when you let the application running before starting the debug, there’s something else…
You could have a try to reflash the module’s Firmware again, even if it shouldn’t change anything, as GDB stub doesn’t save any persistent state to flash. You should have also a look if there are some “arm-elf-gdb.exe” zombie process running even when all debug sessions are closed.
Finally, can you describe a little your application? Is it small enough to post your code here?
Thanks.
Sorry, I didn’t catch your last message.
Previous recommendations are still valid. You should also give a try to modify the TCP port value (default: 10000) in the debug configuration settings.
You should maybe also try deleting the debug configuration and create it again through Debug As > Open AT Target Application menu item…
Thanks daav, but none of the recommendations worked, it just stays there, no active processes, I have tried reloading the OS, same timeout errors. I have created new project with few lines app, loaded it on the modem via target management, started it, it started outputting the messages, then created new debug configuration and debugged. Strange enough, I wasn’t asked by the debug if I want or don’t want the application to be downloaded, it just did it right away and got to the timeout phase. When I ran second time, I got asked, but not much of a difference.
I’m attaching the app in question, tho I don’t think it is the reason for it, someting general happened to the debug.
DebugTest.zip (516 KB)
Indeed, probably nothing to do with your application itself…
Please can you provide two additional files:
- your workspace error log (/.metadata/.log file)
- a persisted version of your launch configuration: go to your Debug Configuration settings dialog, on the “Common” tab, click “Save as: shared file”; this will create a xxx.launch file that you’ll be able to attach here
Thanks.
Hehe absolutely nothing to do with the application itself indeed - a program have decided to open that 10000 port you use for the debugger and there was actually nothing in the log to indicate that debugger cannot listen on that port 
Well it was stupid problem, but can easily waste quite some time if no error message is presented, if you can, put some user-friendly error in the next version.
Ok, that’s the explanation…
But some error should be displayed in the log around that… No error displayed in the error log view? (Window > Show View > Other > General > Error Log)
I’ve got it! When a program binds on all local interfaces on this 10000 port, then dev studio gives error box with “GDB server unavailable” or something like that. But when some program is bound to my IP instead, i.e. 192.168.0.24 for example, then there is no error box, the console fills with timeouts, the error log contains absolutely nothing, only the line:
eclipse.buildId=unknown
java.version=1.6.0_23
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=bg_BG
Command-line arguments: -os win32 -ws win32 -arch x86 -data @noDefault
Info
Wed Apr 06 10:07:34 EEST 2011
Starting server on port 10000The only errors that show in the log are when you try to kill the debug session and when arm-elf-gdb.exe crashes, attaching log of it.
log.zip (1.09 KB)
Thanks for the investigation. We’ll have a look to enhance errors reporting in such cases, allowing an easier diagnostic of the issue.