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
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).
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!
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.
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:
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.
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.
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
!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:
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
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
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?
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.