I cannot debug my application using the Embedded GDB debug method (Can debug in RTE mode):
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 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.
JTAG Debug:
I do not have a JTAG probe and AT+WDEBUG? returnsL +CME ERROR: 3. Log_GDB.zip (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?
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…)
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:
Windows 7 64-bit
Developer Studio 2.1.0.201108081252-R6801
FW: 7.46.0.201108091301
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.
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:
delete any existing launch config
build your embedded app, download it, and make sure it is running on the target.
obviously make sure a 7.45 (or better 7.46) FW is running on the target
make sure the target is running in Development Mode, with “persistence” enabled (should be the default: Development mode is still enabled over a reset)
Create a new launch config, through your project’s right click menu > Debug As… > Open AT Target application
This should ask you for the port to be used for this project.
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…)
build your embedded app, download it, and make sure it is running on the target.
Done
obviously make sure a 7.45 (or better 7.46) FW is running on the target
Done
make sure the target is running in Development Mode, with “persistence” enabled (should be the default: Development mode is still enabled over a reset)
Done
Create a new launch config, through your project’s right click menu > Debug As… > Open AT Target application
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.
From there it should run…
No, it still gives me the same errors as mentioned above…
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…
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.
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.
