Cannot debug in Embedded GDB mode

How does one get Embedded GDB debugging to work?

I cannot debug my application using the Embedded GDB debug method (Can debug in RTE mode):

  1. Embedded GDB
    The firmware package running on the SL6087 chip is 7.45. I double-checked this by running the ATI9 command. When I run the project: Debug As Open AT Target application, the debug view is opened, the firmware is downloaded successfully and then the following errors is shown in the console window:
    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…
    …[some more of the same errors]…
    Malformed response to offset query, timeout

I will attach the log file.

  1. RTE mode
    Got this working by following this post:
    [url]Debugging in M2MS: Unresolved breakpoint issue? [SOLVED]]

I have successfully installed the com0com 64-bit driver and the following is returned from its list command:
CNCA0 PortName=COM98
CNCB0 PortName=COM99

I set a breakpoint.

The active build config is: [RTE]_MinGW_Debug
I run the app using: Debug As > Open AT RTE application

The RemoteTasks monitor is opened and I press the start button [Also tried to debug by first setting the trace levels and/or reading from target]: It goes into running state.
There is a exclamation token at my breakpoint: Unresolved breakpoint

There are also a number of warnings in the console window like:
warning: CSelima::AddFlow(3, 0xb)

Even though the code where the breakpoint is located does run, it never breaks at the set breakpoint.

  1. JTAG Debug:
    I do not have a JTAG probe and AT+WDEBUG? returnsL +CME ERROR: 3. (1.3 KB)

Concerning JTAG, it is available only on WMP products.
Concerning the RTE, sounds like there is an issue in the generated files or configuration: could you have a look to the .gdbinit file located in the [RTE]_MinGW_Debug output directory? (and dump it contents here)
Concerning embedded GDB, it seems you’re not so far to make it working. Sometimes DS fails to start the embedded application and in this case debugging falls in timeout (like in your case…). Could you ensure that the application is started and running on the module before starting the debug session?

Thank you for the reply.

Got the RTE working following another post (I updated my original post with this info)

What do you mean by:

The app is running on the module (it was downloaded and run using the run command) - is there another way that it should be run?

I also tried stopping and starting the app using the AT+WOPEN command and then to start the debug session but to no avail.

If you got troubles with the RTE debug configuration creation, there should be also issues with the “Target” one… As you saw in the post you mentioned, debug configuration creation depends on the selected project when you’re creating it from the toolbar button.
Maybe could you do the try to delete the debug configuration (from the “Debug…” dialog), close this dialog, and then create a new debug config from the project’s right-click menu > Debug As… > Open AT Target Application.
If it doesn’t help, maybe could you add to the post screenshots of the various tabs of your debug config; or even better, save the debug config in a shared file (cf last tab of the configuration in the Debug… dialog), and attach it here with the project (even if it’s a simple Hello World one…)

I have the exact same problem. Here’s what i do:

1: I build my software in target debug mode.
2: I then download it and make sure that it runs.
3: I choose Debug as -> OpenAT Target mode
4: The debugger starts up but keeps saying:

Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending packet: $qSupported#37...Timed out.
Timed out.
Timed out.
Packet qSupported (supported-packets) is supported
warning: unrecognized item "timeout" in "qSupported" response
Sending packet: $?#3f...Ignoring packet error, continuing...
Sending packet: $?#3f...Sending packet: $?#3f...Sending packet: $?#3f...

I can see on the serial lines that it sends data to the module.

I must say, i have never worked with so poor development tools for any hardware that we have used in our company so far.


Just a rapid check: are you using a 7.45 or 7.46 FW? What is your DS version?

Windows 7 64-bit
Developer Studio

COM0COM (or whatever the name is) is running.

As you probably know from some of my earlier posts, debugging wavecom modules have been a real pain since you went from visual studio to m2m studio. RTE debugging only works sometimes and often goes down in the middle of it.

Embedded debugging doesn’t work at all. I have been fighting with these issues for over a year now.

Do you mean Traces, etc, or “real” debugging - with JTAG?

No, i mean the new Embedded Gdb debugging in fw 7.45 or newer.

But I thought you said you’d been fighting it for, “over a year” ?

Has the Embedded GDB been available for that long :question:

Embedded GDB is available from FW 7.45, since February or March 2011.
And it’s clearly recommended to use it instead of RTE, which won’t be maintained in future embedded SW releases.

Now, when speaking about Embedded GDB:

  • don’t bother with COM0COM: it’s only required when using RTE.
  • let’s take it from the beginning; we saw your request on another post to have more tutorials on debugging setup, and it’s probably true that things which seem obvious for us are not for others… A new “Developers Site” is under construction, and aims to host this kind of resources in a near future. Meanwhile, let’s setup it again:
  1. delete any existing launch config
  2. build your embedded app, download it, and make sure it is running on the target.
  3. obviously make sure a 7.45 (or better 7.46) FW is running on the target
  4. make sure the target is running in Development Mode, with “persistence” enabled (should be the default: Development mode is still enabled over a reset)
  5. Create a new launch config, through your project’s right click menu > Debug As… > Open AT Target application
  6. This should ask you for the port to be used for this project.
  7. From there it should run…

But we have known issues we’re investigating for fixes:

  • sometimes the used port in the launch configuration is not saved correctly, and you have to re-enter it in the dialog each time.
  • sometimes the TCP port isn’t closed correctly, from one session to another, and you have to change it on each try.

If you still have issues, please don’t hesitate to attach logs to this topic (workspace, GDB, etc…)

  1. delete any existing launch config

  2. build your embedded app, download it, and make sure it is running on the target.

  3. obviously make sure a 7.45 (or better 7.46) FW is running on the target

  4. make sure the target is running in Development Mode, with “persistence” enabled (should be the default: Development mode is still enabled over a reset)

  5. Create a new launch config, through your project’s right click menu > Debug As… > Open AT Target application

  6. This should ask you for the port to be used for this project.
    No, it does not ask about any comport. If i open the configuration then it is set to COM1 and if i change it and then go back to the configuration it is again COM1. Fortunately i can use COM1 so that should not be a problem.

  7. From there it should run…
    No, it still gives me the same errors as mentioned above…

Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, timeout

Here’s a log more:

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...

EDIT: I made a video to show you what i do:

Thanks to took time to demonstrate that… you’re just doing the things right!..
Now we have to understand what’s going wrong there.
Please can you attach here:

  • the workspace log (.log file in your /.metadata folder)
  • the gdb log (gdb_logfile.txt collocated with gdbcmd.ini file in you folder)

By the way, here are some answers to your “questions” (I had to guess them since can’t get the sound working on the video):

  • we have indeed noticed a “persistence” bug on the chosen serial port in the debug configuration. Logged for fix in the next release.
  • the gdbcmd.ini file is workspace-global since it doesn’t contain anything else that configuration for the GDB log.

Meanwhile, we’re getting in touch with embedded debugger team to try going further on the analysis…

Some other tips:
Please can you check the generated.c file content of your project?
Content should look like this (“Debug compilation mode” defined):

Indeed, since FW7.46, the application has to link vs OS 6.36 library, and be compiled in Debug configuration to enable embedded debugging.
This has to be considered as a protection: when you have units on the field, embedding an application built in release mode, nobody can’t setup a debug session with it since FW will refuse it.
In your specific case, all seems to be OK, but maybe there is a bug…

We also need internal debug messages from the debugger; please can you:

  • go to traces configuration, select the “Remote traces” tab, and click the “Use Firmware package” button
  • then go back to “Levels filter”, and enable the SYS-28 level (you’ll have to first remove the “Display only application flows” filter)
    Try to setup your debug session, and please send any trace sent on this SYS-28 level.


That might be it! I do not use the generated.c file! I will add the missing statements and check if that was the problem. If it is, i strongly suggest that this should be documented. It is not mentioned anywhere in the embedded debug help that you need this file for it to work.

Ok, now that i added the code from your post, it can send the packets!

It still doesn’t work though. Now it says the following in the console window when i try to debug:

Indeed; if Application Settings editor is disabled, we’ll have to put somewhere an explicit warning around the “ADL Compilation Mode” definition, which is defined to “Release” by default.

Actually, this message is “normal” in the gdb console, and doesn’t mean that the debug session is not possible.
Did you try to set a breakpoint?
Note that breakpoints on the early lines of task entry points won’t stop the execution: we have to add some synchronization mechanism at debugger level to make this possible.
Please note also that by default, launching the debug session doesn’t reset the module, but “catch” the application where it is currently running.
You can specify it differently in the debug configuration, by asking explicitly for module reset when starting the debug session.

Here’s the trace info you requested:

166,579 1-environment-cd D:/Projekter/SiWi/workspace/siwo_soft
166,595 1^done
166,595 (gdb) 
166,595 2-file-exec-and-symbols D:/Projekter/SiWi/workspace/siwo_soft/[Target]_ARM_EABI_GCC_Debug/si\
166,610 2^done
166,610 (gdb) 
166,610 3-gdb-set auto-solib-add on
166,626 3^done
166,626 (gdb) 
166,641 4-environment-directory D:/Projekter/SiWi/workspace/siwo_soft D:/Projekter/SiWi/workspace/si\
wo_soft/.settings D:/Projekter/SiWi/workspace/siwo_soft/.settings/.svn D:/Projekter/SiWi/workspace/s\
iwo_soft/.settings/.svn/prop-base D:/Projekter/SiWi/workspace/siwo_soft/.settings/.svn/props D:/Proj\
ekter/SiWi/workspace/siwo_soft/.settings/.svn/text-base D:/Projekter/SiWi/workspace/siwo_soft/.setti\
ngs/.svn/tmp D:/Projekter/SiWi/workspace/siwo_soft/.settings/.svn/tmp/prop-base D:/Projekter/SiWi/wo\
rkspace/siwo_soft/.settings/.svn/tmp/props D:/Projekter/SiWi/workspace/siwo_soft/.settings/.svn/tmp/\
text-base D:/Projekter/SiWi/workspace/siwo_soft/.svn D:/Projekter/SiWi/workspace/siwo_soft/.svn/prop\
-base D:/Projekter/SiWi/workspace/siwo_soft/.svn/props D:/Projekter/SiWi/workspace/siwo_soft/.svn/te\
xt-base D:/Projekter/SiWi/workspace/siwo_soft/.svn/tmp D:/Projekter/SiWi/workspace/siwo_soft/.svn/tm\
p/prop-base D:/Projekter/SiWi/workspace/siwo_soft/.svn/tmp/props D:/Projekter/SiWi/workspace/siwo_so\
ft/.svn/tmp/text-base D:/Projekter/SiWi/workspace/siwo_soft/Dokumentation D:/Projekter/SiWi/workspac\
e/siwo_soft/Dokumentation/.svn D:/Projekter/SiWi/workspace/siwo_soft/Dokumentation/.svn/prop-base D:\
/Projekter/SiWi/workspace/siwo_soft/Dokumentation/.svn/props D:/Projekter/SiWi/workspace/siwo_soft/D\
okumentation/.svn/text-base D:/Projekter/SiWi/workspace/siwo_soft/Dokumentation/.svn/tmp D:/Projekte\
r/SiWi/workspace/siwo_soft/Dokumentation/.svn/tmp/prop-base D:/Projekter/SiWi/workspace/siwo_soft/Do\
kumentation/.svn/tmp/props D:/Projekter/SiWi/workspace/siwo_soft/Dokumentation/.svn/tmp/text-base D:\
/Projekter/SiWi/workspace/siwo_soft/[RTE]_MinGW_Debug D:/Projekter/SiWi/workspace/siwo_soft/[RTE]_Mi\
nGW_Debug/src D:/Projekter/SiWi/workspace/siwo_soft/[Target]_ARM_EABI_GCC_Debug D:/Projekter/SiWi/wo\
rkspace/siwo_soft/[Target]_ARM_EABI_GCC_Debug/src D:/Projekter/SiWi/workspace/siwo_soft/[Target]_ARM\
_EABI_GCC_Release D:/Projekter/SiWi/workspace/siwo_soft/[Target]_ARM_EABI_GCC_Release/src D:/Projekt\
er/SiWi/workspace/siwo_soft/inc D:/Projekter/SiWi/workspace/siwo_soft/inc/.svn D:/Projekter/SiWi/wor\
kspace/siwo_soft/inc/.svn/prop-base D:/Projekter/SiWi/workspace/siwo_soft/inc/.svn/props D:/Projekte\
r/SiWi/workspace/siwo_soft/inc/.svn/text-base D:/Projekter/SiWi/workspace/siwo_soft/inc/.svn/tmp D:/\
Projekter/SiWi/workspace/siwo_soft/inc/.svn/tmp/prop-base D:/Projekter/SiWi/workspace/siwo_soft/inc/\
.svn/tmp/props D:/Projekter/SiWi/workspace/siwo_soft/inc/.svn/tmp/text-base D:/Projekter/SiWi/worksp\
ace/siwo_soft/itf D:/Projekter/SiWi/workspace/siwo_soft/itf/.svn D:/Projekter/SiWi/workspace/siwo_so\
ft/itf/.svn/prop-base D:/Projekter/SiWi/workspace/siwo_soft/itf/.svn/props D:/Projekter/SiWi/workspa\
ce/siwo_soft/itf/.svn/text-base D:/Projekter/SiWi/workspace/siwo_soft/itf/.svn/tmp D:/Projekter/SiWi\
/workspace/siwo_soft/itf/.svn/tmp/prop-base D:/Projekter/SiWi/workspace/siwo_soft/itf/.svn/tmp/props\
 D:/Projekter/SiWi/workspace/siwo_soft/itf/.svn/tmp/text-base D:/Projekter/SiWi/workspace/siwo_soft/\
src D:/Projekter/SiWi/workspace/siwo_soft/src/.svn D:/Projekter/SiWi/workspace/siwo_soft/src/.svn/pr\
op-base D:/Projekter/SiWi/workspace/siwo_soft/src/.svn/props D:/Projekter/SiWi/workspace/siwo_soft/s\
rc/.svn/text-base D:/Projekter/SiWi/workspace/siwo_soft/src/.svn/tmp D:/Projekter/SiWi/workspace/siw\
o_soft/src/.svn/tmp/prop-base D:/Projekter/SiWi/workspace/siwo_soft/src/.svn/tmp/props D:/Projekter/\
166,641 4^done,source-path="D:/Projekter/SiWi/workspace/siwo_soft;D:/Projekter/SiWi/workspace/siwo_s\
166,641 (gdb) 
166,641 5-target-select remote localhost:10000
167,023 5^connected,thread-id="0",frame={addr="0x00000000",func="??",args=[]}
167,023 (gdb) 
167,023 6-break-insert siwo_http.c:68
167,039 6^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0026dad0",func="ht\
167,039 (gdb) 
167,055 7-exec-continue
167,055 7^running
167,055 (gdb) 
167,160 ~"Can't send signals to this remote system.  SIGEMT not sent.\n"


set debug remote 1
set remotelogfile D:\Projekter\SiWi\workspace\gdb_logfile.txt

Did you see the post I sent just before?
The logs indicate that the breakpoint is successfully set; isn’t it stopping the execution now?