How do i debug?


#1

Hi

I just waisted 4 hours trying to figure out how to debug in M2M Studio. An action that just requires one to hit a single button in Visual Studio is rocket science in M2M Studio with an endless list of cryptic bugs.

How do run an RTE debug?? The help files says to just Debug As -> Open AT RTE, however there are no “Open AT RTE” to choose!

If i then try to debug in target mode all sorts of errors pops up: java.lang.NullPointerException, Program not being run, retrieve backtrace which never completes, freezing IDE etc.

When i hit run i get this in the debug perspective:

load C:\\OpenAT\\workspace\\siwo_soft\\[Target]_ARM_ELF_GCC_Debug\\siwo_soft.axf 
You can't do that when your target is `None'
continue
The program is not being run.
The program is not being run.

I can’t even figure out where to start to get this simple task to work in M2M Studio!!

EDIT:

I now tried creating a new project, based on the hello world sample. I cannot debug this project either. Not in RTE mode nor in target mode.

If I try to do it in RTE mode it launches the COM0COM setupc.exe but quits and just states that there was a problem and then stops the debug job.

If I try to debug in target mode, i get the null pointer exception.

It’s almost like sierra wants to get rid of it’s customers :slight_smile:


#2

I have the same issue, Com0Com driver must be installed to have a successful debug, but I couldn’t manage to get it installed.

There is a file at C:\Program Files (x86)\com0com\setupc.exe and I can do something using that console, but I don’t want to do something wrong.

Ps. I have Microsoft Windows 7 x64 Ultimate


#3

Some precisions about debugging with DS (also mentioned in the documentation).
Until now, there are indeed two ways of debugging:

  • either in “Target mode”, through a JTAG probe. You need additional hardware to make this solution running, and this is only possible on WMP modules.
  • or in “RTE mode”

About RTE:
in this mode your application has to be built with MinGW compiler (Note: you have to make sure that the MinGW build configuration is selected on your project prior to try debugging your app), and will actually run on your PC (as if it was a Windows application; the app is not downloaded on the target in this mode).
Please note that this is not a full simulation mode, as the app is still connected to the target (it still can use APIs to handle AT commands or others, as if it was really running on the target).

Now, two last words:

  • we indeed need (since DS 1.2.0) an additional driver (COM0COM) to be installed on the system to make the RTE running. It’s true that if the install fails, the RTE debug session can’t run successfully. We’re going to make some investigations on Windows 7 to try to reproduce the issue. As soon as we get a workaround, I let you know.
  • we’re currently working on a new debug solution, with the application running on the target, and without extra material (JTAG probe).

#4

And the third way:

  • Use the Traces

(of course, this doesn’t give you breakpoints, etc)


#5

We’re not using Windows 7 here. We’re using:
Windows XP Professional SP3 (Danish)
Developer Studio 1.2.0 Build Version 1.2.0.201012171243-R6026

Would it be possible for you to supply the required configuration for COM0COM setup.exe? Then i could try configuring it manually.


#6

You can grab it from here: http://com0com.sourceforge.net/
RTE running requires COM98 & COM99 virtual ports to exist and be interconnected.


#7

It still won’t work with manual configuration as DS will just disable and re-configure the ports when starting debug mode, which then aborts with an installation error.

I really hope that Sierra will find a solution FAST as we are not able to keep our time targets towards our customers because of this problem not being able to debug!


#8

I had this problem… I decompiled sierra wireless eclipse plugin to see what it was doing to install com0com.

you have to set up a com98 and a com99 pair

and make sure you get the 64bit com0com. and read the readme…as the driver is signed as a test driver not a proper driver. But the readme explains what you have to do.

Also, I cross compile, So I do most of my development in visual studio and then retarget for the hardware. Mainly so I can unit test the code first. You simply mock out the api calls.


#9

We use 32 bit windows here. I tried creating com98 and com99, however it always names them CNCA0 and CNCB0 and then I have to rename them. This rename does not affect the port name in control panel so i’m not sure i’m getting it configured properly.

EDIT: I got it working by issuing the following commands from the console version of the com0com:

change CNCA0 PortName=COM98
change CNCB0 PortName=COM99

EDIT 2: Well, now it properly starts the serial port monitor in the systray. But rte_kernel.exe now aborts with the following message:

MinGW gdb: You can't do that without a process to debug.

The console window under debug perspective also mentions something about “unable to auto-solib-add”, but the message disappears as soon as the above mentioned error pops up.

I have a working MinGW build and the project is just the sample hello world project included with DS.


#10

Ok: this explains why DS continue to try installing: it didn’t detect COM98 & COM99, so it kept on trying…
Hope you can debug now.

However it doesn’t explain why DS failed to install com0com automatically.
If you can take 2 minutes to attach the DS log to this post, this would help us to investigate why (just remade the try here on a fresh new XP 32bits install without any issue):

  • locate the .log file in the .metadata directory
  • zip it and attach it here

What was the behavior in the automated install? Did it fail immediately, or during the com0com setup?
TIA for your answers.


#11

Maybe your debug configuration is corrupted by the previous tries.
Just delete it (go to Debug configurations dialog, select it, delete it, and close the dialog)
And then recreate a new one by selecting your project > right click > Debug As > Open AT RTE Application


#12

Indeed the log shows the problem:

!ENTRY com.wavecom.openat.ide.ebs.launch.rte 4 0 2011-02-11 11:58:04.875
!MESSAGE COM0COM driver install failed, path not found: C:/Programmer/Sierra Wireless/Developer Studio/tools/com0com/setupc.exe
!STACK 0
com.wavecom.openat.ide.ebs.targetbinding.selima.SelimaHandlingException: COM0COM driver install failed, path not found: C:/Programmer/Sierra Wireless/Developer Studio/tools/com0com/setupc.exe
	at com.wavecom.openat.ide.ebs.targetbinding.selima.COM0COMManager.getLocalInstallerPath(COM0COMManager.java:189)
	at com.wavecom.openat.ide.ebs.targetbinding.selima.COM0COMManager.installCOM0COMPorts(COM0COMManager.java:102)
	at com.wavecom.openat.ide.ebs.targetbinding.selima.COM0COMManager.installIfNeeded(COM0COMManager.java:88)
	at com.wavecom.openat.ide.ebs.launch.rte.RTELaunchDelegate.preLaunchCheck(RTELaunchDelegate.java:103)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:808)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:923)
	at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1126)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

DS did not install com0com in the above mentioned folder! It was installed here:

C:\Programmer\com0com

I’ll try and move it to the correct location.

Thanks for your support


#13

Ok, i will try that.

And moving com0com to the right location fixed the install issue with com0com. However i still have the abort error with the debug process:

auto-solib-add on
Undefined command: "auto-solib-add".  Try "help".
You can't do that without a process to debug.

#14

Isn’t it the location where you installed it manually?

This warning is “normal”.
You’ll see when it will work that RTE issues a lot of warnings in the gdb console. Please simply ignore them (too huge refactoring work to clean them, and as I said above, we’re working on a completely different solution now).

This one shouldn’t appear.
Some points to verify:

  • your application has to be built with MinGW build configuration
  • MinGW build configuration has to be the active one
  • Check the output folder contains rte_kernel.exe, OatAppli.dll + 4 other dlls
  • Check that the Firmware package on which your application is depending on (cf Project Properties > Open AT Application page) matches with the one currently running on the target.
  • Do the try mentioned above to delete + re-create the debug configuration

If you still have issues, please make screen captures of the “Main” and “Debugger” tabs of your Configuration in the “Debug Configurations…” dialog


#15

No, I never manually installed com0com. I never knew what it was or that i had to use it before i tried debugging in RTE mode.

Ok, thanks.

  • your application has to be built with MinGW build configuration --> OK
  • MinGW build configuration has to be the active one --> OK
  • Check the output folder contains rte_kernel.exe, OatAppli.dll + 4 other dlls --> FAIL!
  • Check that the Firmware package on which your application is depending on (cf Project Properties > Open AT Application page) matches with the one currently running on the target. --> OK
  • Do the try mentioned above to delete + re-create the debug configuration --> Tried, doesn’t help.

The only files present in the [RTE]_MinGW_Debug folder is the following ones:
\src\generated.o
\src\hello_world.o
export.def
rte_Kernel.exe

export.def


#16

So you didn’t use the installer link I provided above? (http://com0com.sourceforge.net/)
We’ll take a look on that point…

Sounds like your application didn’t link with MinGW… Don’t you have errors in the build console?


#17

I get this if i try to build my minGW build:

OatAppli.exp(.edata+0x38):fake: undefined reference to `opec_cusGetHeader’

To get rid of this message i have to remove “opec_cusGetHeader @1” from export.def.

I wonder if this is why it doesn’t work?


#18

Yes it is.
Actually the rte_Kernel.exe file is not the build result: it is a loader for the built application, which is created as OatAppli.dll
You don’t have to modify export.def, and now we have to check why your app doesn’t link correctly.
Please can you erase the build output directory, retry a full build, and post the full build console log?


#19

Reproduced here: com0com installer in silent mode weirdly processes installation paths with spaces.
And it indeed doesn’t matter if you’re on XP, or 7 or others…
Bug is fixed now, and will be integrated in next release.
Thanks for the help on investigation.


#20

Should be avoided at all costs!!