Target management has been improved with OS Awareness. This is bringing much more visibility to Open AT application execution with some insight on Task status, Stack status and peak consumption, and Heap size and current usage.
The ability to Record & Replay on UART which was existing on legacy TMT is now available as well with Developer Studio.
USB Robustness has been improved, thanks to a revamp of the USB driver.
JTAG configuration for some WMP customers has been improved, to ease its usage with Segger probe.
Conditionnal Breakpoints with embedded debugging which was already available, is now fully validated.
How to prevent DS from reading “target information” from the device whilst trying to upload files? That information is never readable on my FXT009’s, previous DS disregarded that and did upload, and this one gets stuck.
I have the same problem when opening a USB COM port with an FXT009. These are the error details from the error message popup:
Open and load port COM7 => ERROR: Time out: 20000ms
Open and load physical port COM7 => ERROR: Time out: 20000ms
Open port COM7 => DONE: Port opened
Load informations from target => ERROR: Time out: 20000ms
Waiting for module detection => DONE: Target detected sn:BH1230091708100 baudrate:null
Switch to Development mode and check => DONE: Success
Switch to Development mode => DONE: Success
Waiting for module detection => DONE: Target detected sn:BH1230091708100 baudrate:null
Check dev mode unlocked => DONE: Success
Load model element: IMEI => DONE: IMEI received: [353270040346407]
Load model element: Target Informations => ERROR: Time out: 20000ms
Load model element: Target Informations => ERROR: Time out: 20000ms
Load model element: Target Informations => ERROR: Time out: 20000ms
and this is what’s in the console window:
----------------- Port opened -----------------
OK
Serial Number BH1230091708100
OK
OK
+WIMEI: 353270040346407
OK
+WDM: 3
OK
+WOPEN: 6,1024,4096
OK
+WOPEN: 1
OK
+CME ERROR: 3
“- USB Robustness has been improved, thanks to a revamp of the USB driver.”
In device manager, the driver (in the modem group, not sure if this is the correct one) is still version 3.6.5 from August 2010
Please go to the sierrawireless.com/Support/Downloads.aspx page, choose your AirPrime product, and grab the latest 3.8.2 USB driver (at the bottom of the page)
A new USB support page has been added to the Developer Studio online help. Please have a look and check if it helps.
We’ve tested this now with 4 different modems, 2 FXT009 and 2 FXT 003, all running FW ver 7.46 and bootloader ver V08b11. One of the 4, an FXT003, can be opened from DS 2.1.1 every time we try it, none of the other 3 can. The key difference we see is the three that don’t work show up in device manager under the modems group, and the one that works shows up in the ports group.
In the devices tab in DS, the 3 that don’t work have type USB (Modem), while the one that does has type USB (COM). Also the 3 that don’t work don’t work if you try to connect by the serial port either. The one that works can be successfully opened using either the serial port or the USB port. 3 of the 4 modems including the one that works are brand new out of the box.
On the targets which are not connecting, please can you:
clear the console content
request a refresh in the target status view
copy-paste the console content here?
We can see a “+CME ERROR: 3” result in your console log, please can you check if there is a difference in AT+CMEE configuration between your 3 non-working targets, and the working one?
We’ve managed to get all 4 modems working now. There were a few issues causing the difficulties:
The new USB driver didn’t install with the upgrade to v2.1.1 (not sure if it’s supposed to or if it always required a separate installation)
A couple of the modems had AT+CMEE set to 1 - opening the port times out if CMEE is 1, which I suspect is new behaviour with 2.1.1 (at least we’ve never noticed it before)
One of the modems had a firmware version of 7.43, where a minimum of 7.45 seems to be required for the new driver. I had assumed the modems were all running 7.46 as they came in the same shipment.
The USB driver indeed requires a separated (and manual) installation/update. We’re studying the possibility to have a notification mechanism also for the USB driver updates…
Can you remember which FW version is running when you get troubles while +CMEE=1 is active? From what we’ve tested, connection seems always successful with +CMEE=1 and FW version 7.46, but we could get trouble with former versions.
Indeed, the command used to switch USB mode (AT+WUSB) requires FW 7.45 or higher.
It’s happening with all firmware versions including 7.46. Here are the contents of the error message popup after the timeout:
Reload model for port COM15 => ERROR: Time out: 20000ms
Load informations from target => ERROR: Time out: 20000ms
Waiting for module detection => DONE: Target detected sn:BH1230091708100 baudrate:null
Switch to Development mode and check => ERROR: Time out: 1000ms
Switch to Development mode => DONE: Success
Waiting for module detection => DONE: Target detected sn:BH1230091708100 baudrate:null
Check dev mode unlocked => ERROR: Time out: 1000ms
Switch to Development mode and check => DONE: Success
Switch to Development mode => DONE: Success
Waiting for module detection => DONE: Target detected sn:BH1230091708100 baudrate:null
Check dev mode unlocked => DONE: Success
Load model element: IMEI => DONE: IMEI received: [353270040346407]
Load model element: Target Informations => ERROR: Time out: 20000ms
Load model element: Target Informations => ERROR: Time out: 20000ms
Load model element: Target Informations => ERROR: Time out: 20000ms
Mmm, could be interresting to understand from which command the “+CME ERROR: 3” result is coming…
Please can you make the test again, with the ATI 1 trace level enabled, and post the trace log (in a file, please)?
Please see below (note attachments of type csv,txt,and log are not allowed, and I don’t know what file types are allowed, so I’ve included the contents inline. My apologies for the length of the post).