Developer Studio 2.0.0 is available for download

IoT Modules Development tools
1

Dear Developer Studio users,

Please note that Developer Studio 2.0.0 is available for download from now.
An automatic update should be proposed the next time you’ll open your Developer Studio session.

This new delivery is synchronized with Open AT Software Suite 2.35 version, in order to let you use the major new feature of these new releases: Open AT applications debugging, on the target, and without extra hardware required (i.e. without JTAG probe).
This new functionality is compatible with all the modules able to run the 7.45 Firmware version.

The other major update of this new 2.0.0 version is the ability, when installing Developer Studio for the first time (using the installer), to select the components to install, allowing a lighter product setup if you don’t need all the features.

For more information concerning the new release, please refer to the Developer Studio 2.0.0 release note at http://www.sierrawireless.com/en/Support/AirPrime/releasenotes/Developer_Studio_2_0_0.aspx

Enjoy using Developer Studio 2.0.0!

2

Will that replace the existing installation?

If I want to retain my existing installation, do I need to effectively do a “first-time install” to a separate folder?

I trust it still works with older versions?

Where is this documented?

3

If you do the update, yes.

Yes, you should do this if you want to keep both versions.

Yes, you can use Software Suite 2.35 with DS 1.2.0 or even 1.1.2

Online Help of DS have been updated regarding the new handling of Target Debugging.

4

Note that the SiWi support site login is different from the forum login and will break your navigation to that page! :unamused:

See: Discovery Tool release 1.4.0 now available ! - #4 by awneil

5

From the release notes, there’s no link to the actual installer!

It’s here: sierrawireless.com/productsa … tudio.aspx

6

Do you mean with this that it is just still possible to ‘debug’ the target or is this a new feature?

7

Until now, the only way to debug an Open AT application running on the target (I mean using a debugger) was to use a JTAG probe, and was only available on WMP modules.
This method is still available, but in addition, we introduced a new feature allowing to do the same, but without JTAG probe and available on all modules.

8

Sounds very useful - must give it a try…

9

OK, thanks.

10

As I haven’t been able to try 2.0.0 yet, I am very curious – how is it implemented? Is there an gdb server sitting on the target?

11

Indeed, we’ve implemented a “GDB stub” in Firmware 7.45 allowing to handle this functionality. DS communicates with it over the serial line, through frames multiplexed with the other ones (traces, AT commands…)

12

Are there any specific requirements for this type of debugging? For example, any hardware (RAM) requirements?

13

Nothing specific or extra regarding the normal execution conditions for your Open AT application…

14

Hey guys, excited about this new version I grabbed it and did clean install using default selections without the Discovery Tool. From the toolchains only the ARM EABI GCC was selected. My project failed to build, I created new one and copy pasted the source and include files and it built just fine. However when I try to do target debug I get this error:

java.io.IOException: Cannot run program "gdb": Launching failed
	at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:297)
	at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:88)
	at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:116)
	at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:108)
	at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:63)
	at org.eclipse.cdt.debug.mi.core.MIProcessAdapter.createGDBProcess(MIProcessAdapter.java:115)
	at org.eclipse.cdt.debug.mi.core.MIProcessAdapter.getGDBProcess(MIProcessAdapter.java:51)
	at org.eclipse.cdt.debug.mi.core.MIProcessAdapter.<init>(MIProcessAdapter.java:38)
	at org.eclipse.cdt.debug.mi.core.command.CommandFactory.createMIProcess(CommandFactory.java:456)
	at org.eclipse.cdt.debug.mi.core.MIPlugin.createSession(MIPlugin.java:460)
	at org.eclipse.cdt.debug.mi.core.AbstractGDBCDIDebugger.createGDBSession(AbstractGDBCDIDebugger.java:114)
	at org.eclipse.cdt.debug.mi.core.AbstractGDBCDIDebugger.createSession(AbstractGDBCDIDebugger.java:68)
	at org.eclipse.cdt.launch.internal.LocalCDILaunchDelegate.launchDebugSession(LocalCDILaunchDelegate.java:344)
	at org.eclipse.cdt.launch.internal.LocalCDILaunchDelegate.createCDISession(LocalCDILaunchDelegate.java:469)
	at org.eclipse.cdt.launch.internal.LocalCDILaunchDelegate.launchLocalDebugSession(LocalCDILaunchDelegate.java:146)
	at org.eclipse.cdt.launch.internal.LocalCDILaunchDelegate.launchDebugger(LocalCDILaunchDelegate.java:113)
	at org.eclipse.cdt.launch.internal.LocalCDILaunchDelegate.launch(LocalCDILaunchDelegate.java:73)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:853)
	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)

Soo… if it tries to run some gdb.exe it won’t have much of a success, as there is only arm-none-eabi-gdb.exe, I tried renaming to gdb.exe and didn’t work either. Missing something?

15

It appears that you didn’t use “Open AT Target Application” launch configuration, but maybe a standard CDT one, which won’t work…
Once your application is built, downloaded and started on the target, you can debug it by:

  • Right click on the project in the project explorer
  • Select Debug As > Open AT Target Application
  • Select the connection on which your target is running

and from there it should run…

16

Thanks, I had OpenAT Target application, but have ran it directly from the menu rather than going to debug configurations and creating new from there, so I deleted the one, created new and… it was crashing with some weird infinite loop exception. Restarted Dev studio and it is working now, very, very handy!

By the way “step over” and “step into” do not work if you already have 2 breakpoints in the code. I understand why, but it took me some time waiting for something to happen when I pressed “step over” and it never came to the next line, but never continued the program either, I had to stop the execution and restart it to continue, maybe just disabling them when you put 2 breakpoints or having a message pops that you cannot now do that.

17

Firmware 7.45 has indeed some limitations around stepping feature; these bugs will be fixed in the next Firmware release.

18

:frowning:
Something happened with the debugging, I was actually able to debug the program only once, I can no longer do it so switched back to the message system, but it is great to get it back online…

Steps I performed:

  1. restart dev studio
  2. go taget management, connect
  3. stop application
  4. at+wopen=3, at+wopen=4
  5. restart dev studio
  6. go taget management, connect
  7. go to openat, debug
  • loading application starts
  • launching application starts
  • error console fills with:
Sending packet: $qSupported#37...Ack
Packet received: E01
Packet qSupported (supported-packets) is supported
warning: Remote failure reply: E01
Sending packet: $?#3f...Ack
Packet received: E01
Sending packet: $Hc-1#09...Ack
Packet received: E01
Sending packet: $qC#b4...Ack
Packet received: E01
Sending packet: $qOffsets#4b...Ack
Packet received: E01
warning: Remote failure reply: E01
warning: Remote failure reply: E01
  • launching stops at 94% and stays there forever

Any idea?

19

happends the same to me

20

This error code comes when the embedded GDB stub detects that the application is either not present or not started. Are you sure that your app is running and alive on the module?