Developer Studio 3.1 - Released

IoT Modules Development tools
1

Developer Studio 3.1 has been released and is now available for download.

If you’re already running Developer Studio 3.0, the update should be proposed the next time you’ll start it, or can be triggered with the Help > Check for Updates menu.
In order to install Developer Studio 3.1, please follow the Getting Started instructions.
For more information on this release content, please read the Release Note

2

Hello

I have installed Developper studio 3.1. I can run and compile applications with FX100 and Q2698 but I can´t import OS2.52 for Q26 family.

On the release notes say that Developer version 3.1 only support OS2.52 and forward but I though that OS2.52 for Q26 family was also included.

I can´t import the frameworks 2.52 for Q26 from updasite.sierrawireless.com

Thanks,
Isabel

3

Hi isabel,
DS 3.X supports 2.52 and higher versions on all modules, so there shouldn’t be any issue.
Please can you elaborate on your problem? 2.52 version is available on the repository and is compatible with DS 3.1 …

4

It´s solved. It took a very long time to update and install OASIS252 pakage from Sierrwireless updatesite. But it´s done it already.

Thanks,

Isabel

5

Hi! I have 64-bit Arch Linux and latest Developer Studio 3.1.
My device is WMP100.
I can build my project, but in Target Management view there are no devices.
So I can’t download the binary onto the device using the Studio.
However, I can use minicom to communicate with the device (it’s /dev/ttyACM0).
Why does the Studio show no connected devices? Do I need to install some specific packages?
Thanks a lot!

6

Is your user part of the dialout group?
Could you give a try with a serial-USB converter?
(Note: devices USB connectivity is not that well supported on Linux, because of resets management: the port identifier may change after a device reset, and we have no easy way to manage that in DS…)

7

Hello. I updated Developer Studio from 3.0 to 3.1 (at least, it seems to me that problems started after update). Now when I open port in developer or production mode (Windows 7 64-bit, FXT009), either USB or COM, the port remains open for 20-30 sec and then suddenly closes. Sometimes everything returns to normal (I am not sure why), but after some time the problems start again. What could that be? Should I reinstall everything?

8

We didn’t make any significant update on this part so it’s hard to imagine that the update could be the root cause of your problem.
Anyway, you could give a try to revert your installation to 3.0 if it gets better… And also try a fresh install…

9

Thank you for response!

I am a part of uucp group as well as dialout. Here are device permissions:

crw-rw---- 1 root uucp 166,  0 Sep  5 16:40 /dev/ttyACM0

Here is dmesg output when the device is connected:

[ 1669.239812] usb 5-1: new full-speed USB device number 3 using ohci-pci
[ 1669.407790] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
[ 1669.407835] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
[ 1669.419148] hid-generic 0003:04D8:00DF.0005: hiddev0,hidraw3: USB HID v1.11 Device on usb-0000:00:13.0-1/input2
10

I reinstalled 3.1 from scratch, but this did not help. I would also like to try 3.0, but cannot understand how to do that. Light installer suggests only 3.1 installation. There is a mention of full installer at “Open AT Application Framework” page, but it says “go to firmware download”, but at firmware download page I only find firmware downloads…

But anyway, what could that be? Why the studio issues “at+wdm=0” command some time after opening the port?

11

It sounds like something getting wrong at port opening, causing DS to close the port…
Please can you zip and upload the workspace log file (.metadata.log)?

12

As we’re mainly supporting Debian/Ubuntu distros, actually DS only “sees” devices belonging to the dialout group.
We’re planning to add a way to tweak this in the next DS release. Meanwhile, you could give a try to chgrp your device to force it belonging to the group. It should work, but I’m afraid you’ll have to redo the operation each time the device resets or is plugged in the system.
Or you could have a look to the udev rules, if you have some knowledge on that…

13

I have changed the permissions of the device using udev rules. Here are updated ones:

crw-rw---- 1 root dialout 166,  0 Sep  8 13:21 /dev/ttyACM0

Update: add user to lock group and ensure that you have r/w access to /var/lock (which in Arch links to /run/lock).
After this everything works just like in Windows.

14

Here it is. It is just the result of opening “Target management” for the first time, then I open port, and it closes.
log.zip (2.43 KB)

15

Sounds good, thanks for the information.

16

It looks like the internal API is not able to open the port at all, and fails after a 20s timeout. We already encountered such kind of troubles with some ports that don’t look compatible with the RXTX java library.
What kind of port is it? (Mother board UART, extension card UART, serial-USB converter, pure USB port)
What is the behavior on other ports?

17

I have 2 ports. One is a COM-port on a PCI-X card. Another one is a USB connection, and virtual COM port, which was created for it. Behavior is the same.

I wonder why it decides there is a failure. After some time I see the reaction of my FXT009, and there is some interchange between the studio and the modem.

Is it possible to extend the timeout?

P.S. From my point of view, the studio acts strangely here. First, it fails to open the port during some fixed period of time. But instead of displaying this and ceasing operation with the port, it continues waiting till the port is open, reads and shows the information from device, and then suddenly “remembers” about failure and closes the port. This does not seem reasonable to me.

18

Agreed :wink:
We need to identify which particular stimulus causes DS to decide to close the port. To identify if this is a potentially recent change, could to verify the behavior of DS 2.3.2 with the ports that are not working with DS 3.1?
You can install DS 2.3.2 with the installer provided here: developer.sierrawireless.com/Res … ework.aspx
(Please just install the Target Management feature from DS, nothing else; note that as soon as you install DS 2.3.2 to a different folder, it can coexist with your DS 3.1 installation)

19

From the first glance everything is the same.

So what about extending timeout?
log2.zip (2.5 KB)

20

So it sounds like this is really related to an incompatibility between your hardware and the RXTX library (the strange thing is that until recently, you didn’t had issues like this…)
Not sure increasing the timeout will change something, but could give a try:
Edit .metadata.plugins\org.eclipse.core.runtime.settings\com.swi.tm.ui.prefs file, and add a com.swi.tm.model.steps.open.OpenPortStep-StepTimeOut = 60000 line to configure the timeout (here one minute, in milliseconds).

My last suggestions would be to give a try to resinstall the hardware drivers, or to try with another serial-USB adapter…