How do i debug?

[Kaare]

@awneil

installation paths with spaces.

Should be avoided at all costs!!

No, software that can’t handle paths with spaces should be avoided We live in 2011 where a file name can be more than 8 chars long, the last name more than 3 chars and paths can have spaces

Software that can’t handle such issues belongs in 1993.

Daav, i’ll make a clean build now and post the results.

[Kaare]

@daav

@Kaare

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?

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?

Here it is: Note, the project is an unmodified “Hello World” sample project.

**** Rebuild of configuration [RTE]_MinGW_Debug for project test ****

**** Internal Builder is used for build               ****
C:\Programmer\Sierra Wireless\Developer Studio\tools\mingw\3.4.2\bin\gcc.exe -D__OAT_API_VERSION__=634 -D__DEBUG_APP__ -D__REMOTETASKS__ -IC:\Programmer\Sierra Wireless\Developer Studio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.34.0.201007281407\resources/ADL/basic -IC:\Programmer\Sierra Wireless\Developer Studio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.34.0.201007281407\resources/ADL/itf -IC:\OpenAT\workspace\test\itf -IC:\OpenAT\workspace\test\inc -O0 -g3 -Wall -c -fmessage-length=0 -fno-common -osrc\generated.o ..\src\generated.c
C:\Programmer\Sierra Wireless\Developer Studio\tools\mingw\3.4.2\bin\gcc.exe -D__OAT_API_VERSION__=634 -D__DEBUG_APP__ -D__REMOTETASKS__ -IC:\Programmer\Sierra Wireless\Developer Studio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.34.0.201007281407\resources/ADL/basic -IC:\Programmer\Sierra Wireless\Developer Studio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.34.0.201007281407\resources/ADL/itf -IC:\OpenAT\workspace\test\itf -IC:\OpenAT\workspace\test\inc -O0 -g3 -Wall -c -fmessage-length=0 -fno-common -osrc\hello_world.o ..\src\hello_world.c
C:\Programmer\Sierra Wireless\Developer Studio\tools\mingw\3.4.2\bin\dllwrap.exe src\hello_world.o src\generated.o -Wl,-( --def=export.def --driver-name g++ C:\Programmer\Sierra Wireless\Developer Studio\dropins\com.wavecom.openat.ide.spm.lib.os.model.6.34.0.201007281407\resources\ADL\rte_wmadl_6.34.0.201007281407.0.0.lib -Wl,-) --dllname=OatAppli.dll
OatAppli.exp(.edata+0x38):fake: undefined reference to `opec_cusGetHeader'
collect2: ld returned 1 exit status
C:\Programmer\Sierra Wireless\Developer Studio\tools\mingw\3.4.2\bin\dllwrap.exe: g++ exited with status 1
Build error occurred, build is stopped
Time consumed: 3469  ms.

[daav]

Mmm, I didn’t noticed it earlier, but the .def file is badly generated.
Content should be (for an OS 6.34):

LIBRARY   OATAPP
EXPORTS
   mos_GetHeader    @1

So it explains why it doesn’t link.
Now, why is the .def badly generated… In your Project properties, please can you:

• Go to C/C++ Build > Build Variables page
• Enable Show System Variables checkbox
• Look for WmOatIdeRteDefFile definition
• Check the pointed export.def file content
  Thanks.

[Kaare]

@daav

Mmm, I didn’t noticed it earlier, but the .def file is badly generated.
Content should be (for an OS 6.34):

LIBRARY   OATAPP
EXPORTS
   mos_GetHeader    @1

So it explains why it doesn’t link.
Now, why is the .def badly generated… In your Project properties, please can you:

• Go to C/C++ Build > Build Variables page
• Enable Show System Variables checkbox
• Look for WmOatIdeRteDefFile definition
• Check the pointed export.def file content
  Thanks.

The value of WmOatIdeRteDefFile is:

${workspace_loc}\.metadata\.plugins\com.wavecom.spm.model\templates\export.def

And the content of that template file is:

LIBRARY   OATAPP
EXPORTS
   opec_cusGetHeader    @1

I updated my version of OpenAT after I installed DS 1.2.0, but that shouldn’t pose any problems should it? I mean, I should be able to download a new firmware from your repository and use it without having to re-install DS every time right?

[daav]

@Kaare

I updated my version of OpenAT after I installed DS 1.2.0, but that shouldn’t pose any problems should it? I mean, I should be able to download a new firmware from your repository and use it without having to re-install DS every time right?

Yes of course.
We guarantee DS to be backward compatible with all former package versions. Sometimes recent packages could require a DS upgrade (e.g. some Software Suite 2.34 packages require at least DS 1.1.2), but here you’re using the all latest versions, all is compatible.

Back to your issue: sounds like a project dependency upgrade issue.
The WmOatIdeRteDefFile should point on a file provided in the OS 6.34 folder.
Can you check in the Project Properties > Open AT Application page if the Open AT OS dependency is well positioned to the 6.34 version?
Please can you try "Apply"ing again this dependency update, to check if the variable is updated?
And last questions:

• What was the previous Open AT OS version you used for this project?
• Is there any chance that the project description files are in read-only mode (.project ; .cproject ; .settings.ebsdata files in your project folder) – we already noticed dependencies upgrade issues in this case)?

[Kaare]

@daav

@Kaare

I updated my version of OpenAT after I installed DS 1.2.0, but that shouldn’t pose any problems should it? I mean, I should be able to download a new firmware from your repository and use it without having to re-install DS every time right?

Yes of course.
We guarantee DS to be backward compatible with all former package versions. Sometimes recent packages could require a DS upgrade (e.g. some Software Suite 2.34 packages require at least DS 1.1.2), but here you’re using the all latest versions, all is compatible.

Back to your issue: sounds like a project dependency upgrade issue.
The WmOatIdeRteDefFile should point on a file provided in the OS 6.34 folder.
Can you check in the Project Properties > Open AT Application page if the Open AT OS dependency is well positioned to the 6.34 version?
Please can you try "Apply"ing again this dependency update, to check if the variable is updated?
And last questions:

• What was the previous Open AT OS version you used for this project?
• Is there any chance that the project description files are in read-only mode (.project ; .cproject ; .settings.ebsdata files in your project folder) – we already noticed dependencies upgrade issues in this case)?

Under the OS tab it says: Open AT OS Package (6.34.0.201007281407).

However I get a warning on the Open AT application page right under the “Available Target platform”:

There is no common SDK Profile between this package Open AT OS Package (6.34.0.201007281407) and some plugins

Please note again, this is on a sample hello world project which uses no plugins.

Please can you try "Apply"ing again this dependency update, to check if the variable is updated?

I’m not sure what you mean by that? Where should I apply?

[daav]

@Kaare

I’m not sure what you mean by that? Where should I apply?

Just click the Apply button in the “Open AT Application” page.
To be sure I’m understanding well the use case: was this hello world project created with Open AT AS 6.34 dependency, or was it with another version (which one?) and then upgraded to 6.34?

[Kaare]

@daav

@Kaare

I’m not sure what you mean by that? Where should I apply?

Just click the Apply button in the “Open AT Application” page.
To be sure I’m understanding well the use case: was this hello world project created with Open AT AS 6.34 dependency, or was it with another version (which one?) and then upgraded to 6.34?

It was created when I made this thread to simplify the process of finding the problem so it was created with 6.34.

[Kaare]

With the changes to export.def i can get DS to launch the RemoteTasks Monitor program when i hit ‘Debug’. However after that it just sits there. Nothing more happens. The only button i can press is the red ‘Terminate’ button.

If i hit that one it comes up with an error after a while:

Target request failed to interrupt.

Also, why doesn’t DS by default add a RTE debug configuration when you create a new Open At project??

[daav]

@Kaare

With the changes to export.def i can get DS to launch the RemoteTasks Monitor program when i hit ‘Debug’. However after that it just sits there. Nothing more happens. The only button i can press is the red ‘Terminate’ button.

When RTE monitor is invoked, you have to press the Start button (in RTE monitor window) in order to launch the application.
It’s true that the workflow is not obvious, but as I said, it is now considered as a temporary solution while waiting for the new one.

Also, why doesn’t DS by default add a RTE debug configuration when you create a new Open At project??

By using the “Debug as > Open AT RTE application” in the right click menu of the project, the debug configuration is automatically created. Or even simply click the Debug toolbar button while project is selected and RTE build Configuration is enabled, and it will do the same.

[Kaare]

@daav

@Kaare

With the changes to export.def i can get DS to launch the RemoteTasks Monitor program when i hit ‘Debug’. However after that it just sits there. Nothing more happens. The only button i can press is the red ‘Terminate’ button.

When RTE monitor is invoked, you have to press the Start button (in RTE monitor window) in order to launch the application.
It’s true that the workflow is not obvious, but as I said, it is now considered as a temporary solution while waiting for the new one.

Also, why doesn’t DS by default add a RTE debug configuration when you create a new Open At project??

By using the “Debug as > Open AT RTE application” in the right click menu of the project, the debug configuration is automatically created. Or even simply click the Debug toolbar button while project is selected and RTE build Configuration is enabled, and it will do the same.

I do push the start button - this behaviour is the same as with visual studio. I just forgot to tell you that i did push it

I have now wasted 8+ hours trying to get DS to work. Something that took me 1 hour to get to work perfectly back when you supported visual studio.

[daav]

Mmmm… sounds definitely like there is something wrong there: all of this should work like a charm, and it’s actually the first time we’re hearing about such troubles in setting up the RTE debug on a simple app…
This should be related to the bad export.def reference. Please can you zip your Hello World sample project directory and attach it here?

[Kaare]

@daav

Mmmm… sounds definitely like there is something wrong there: all of this should work like a charm, and it’s actually the first time we’re hearing about such troubles in setting up the RTE debug on a simple app…
This should be related to the bad export.def reference. Please can you zip your Hello World sample project directory and attach it here?

I have now tried clearing the computer from all Wavecom/Sierra related software and then re-installed DS 1.2.0.

This has fixed the export.def issues and also now it adds RTE debug capability as default when i create a new project.

Everything works fine, until the step described above where it gives me the “Target request failed to interrupt” message after i have pushed the ‘Start’ button in the RemoteTask Monitor.

I will attach the sample project shortly.

[Kaare]

I have attached a copy of my sample project.

I created it after i made a clean install of DS.

Before i try to debug i open the proper port and set it to development mode.

My workspace path is: C:\OpenAt\workspace

I had to delete the resources folder to get the size below 1 MB and compress it as rar.
HelloWorld.rar (945 KB)

[daav]

@Kaare

This has fixed the export.def issues and also now it adds RTE debug capability as default when i create a new project.
Everything works fine, until the step described above where it gives me the “Target request failed to interrupt” message after i have pushed the ‘Start’ button in the RemoteTask Monitor.

Sounds better now.
Some things to know about RTE debugging:

• you have to wait a couple of seconds before your application starts in RTE mode (it is not as fast as target mode)
• traces sent by your RTE application are configured in the RTE Monitor dialog (not in DS usual interface): select ADL in the drop-down list + select the desired levels; Traces will appear in blue in the DS traces view.
• sometimes (reproducibility: 10%), application won’t start at all because of synchronization issues between DS and the target.
  These points are not new regarding DS, the behavior was the same with Visual Studio.

Now some restrictions:

• GDB (the debugger we’re using) doesn’t allow to setup breakpoints during execution, so you have to setup them before launching the debug session, or while the execution is stopped (on another breakpoint), otherwise they’ll be ignored.
• Stopping the execution (using “Pause” button) doesn’t work. You must use breakpoints.
• And finally, to properly handle process termination, you have to use RTE monitor Stop and Quit buttons (Stop button from Debug view doesn’t work either).

[awneil]

@daav

Some things to know about RTE debugging:

• you have to wait a couple of seconds before your application starts in RTE mode (it is not as fast as target mode)

This means that the application is likely to miss early WIND notifications, SIM events, etc.

• sometimes (reproducibility: 10%), application won’t start at all because of synchronization issues between DS and the target.

And, if the application relies upon the early WIND notifications and/or SIM events, etc, it will obviously get stuck or confused.

These points are not new regarding DS, the behavior was the same with Visual Studio.

Indeed.

[Kaare]

@daav

@Kaare

This has fixed the export.def issues and also now it adds RTE debug capability as default when i create a new project.
Everything works fine, until the step described above where it gives me the “Target request failed to interrupt” message after i have pushed the ‘Start’ button in the RemoteTask Monitor.

Sounds better now.
Some things to know about RTE debugging:

• you have to wait a couple of seconds before your application starts in RTE mode (it is not as fast as target mode)
• traces sent by your RTE application are configured in the RTE Monitor dialog (not in DS usual interface): select ADL in the drop-down list + select the desired levels; Traces will appear in blue in the DS traces view.
• sometimes (reproducibility: 10%), application won’t start at all because of synchronization issues between DS and the target.
  These points are not new regarding DS, the behavior was the same with Visual Studio.

Now some restrictions:

• GDB (the debugger we’re using) doesn’t allow to setup breakpoints during execution, so you have to setup them before launching the debug session, or while the execution is stopped (on another breakpoint), otherwise they’ll be ignored.
• Stopping the execution (using “Pause” button) doesn’t work. You must use breakpoints.
• And finally, to properly handle process termination, you have to use RTE monitor Stop and Quit buttons (Stop button from Debug view doesn’t work either).

I still have the same problem. If i set a breakpoint in the timer handler in the hello world sample, i never get this breakpoint. After i hit ‘Start’ in the remote task monitor, nothing happens and the debugger gives a yellow triangle at all breakpoints that i set, indicating that they’re unresolved??

If i open the console view, i can see the Hello World messages coming at a faster rate than if i just run the sample in target mode.

[daav]

@Kaare

If i open the console view, i can see the Hello World messages coming at a faster rate than if i just run the sample in target mode.

This shows that the global communication system is functional (your app DLL → RTE kernel → Selima → com0com → DS → your target).
The timer different rate is an already known issue.
Now the last issue is with the debugger: please can you have a look to your RTE Debug Configuration, on the debugger tab (maybe could make a snapshot, and attach it here?). GDB command file should reference a .gdbinit file located in your build configuration output directory. Please can you paste it contents here also?
(Note that you should go through the windows explorer, as Eclipse usually hides .xxx files in the project explorer).

[Kaare]

gdbinit:

symbol-file [RTE]_MinGW_Debug/OatAppli.dll -readnow

For debug options see the attachment.

[daav]

gdbinit file content is correct, but not your debug configuration.
It should look like this:

Note that:

• “RTE Debugger” should be used
• Absolute path to your .gdbinit file has to be configured

Do you remember how did you create this debug configuration?
You should maybe try to delete it and recreate it by the right click menu > debug as… > Open AT RTE application…
Normally all the fields should be automatically and correctly initialized.