Here is a sneak peek of the new Target Management feature list.
Functional scope includes at least the current Target Management’s one, i.e.:
Serial port configuration + open/close
AT commands console
Target information tree
Traces view
Download capability
Following new features will be integrated:
Backtraces decoding, with direct link to the source code editor for known functions in the backtraces
Simultaneous connections to several ports
New concepts for the target connection’s states:
–> “Nominal” mode is now named “production mode”: this is the default UART state
–> “Debug” mode is now named “development mode”: this mode allows Developer Studio to gets traces, backtraces, etc… from the module.
When Developer Studio starts working with a target in development mode, it will set it as a “sticky” state (i.e. still enabled over a module reset)
[TBC] Heap memory status: heap memory snapshot, with blocks addresses, size, and name of the function which has allocated it.
[TBC] Tasks status: application tasks states snapshot, with state (as defined in the ADL execution context API) and call stack consumption (current/max)
(TBC stands for To Be Confirmed: integration will depend on the project advancement)
Improvements coming from the withdrawal of Selima
Serial port opened only on demand, and not more immediately at Developer Studio opening
Target Management support under Linux (except for RTE)
No more brutal crashes, or missed “restart”/“switch workspace” operations
Faster connection setup
Better AT commands performances in production mode
Modified graphical interface (see picture below)
New “Devices” view allowing to control the serial ports connections
New views for new services (Backtraces decoding, Heap memory status, Tasks Status)
All service views by default “pinned” to the selected “master” connection in the Device view
But capability to instantiate several times a service view in order to bind it to another port
Excellent.
This needs to include the facility to import backtraces captured from devices “in the field”.
Does that mean simultansously “managing” several target devices; eg, several Fastracks?
ie, DevStudio will automatically detect when the target restarts, and re-establish the “development mode” comms?
So, in TMT terms, we don’t have to re-do “Init Target” each time the target restarts?
Presumably this will mean that TMT will no longer be usable?
Will there be some equivalent “light-weight” interface for, say, field debugging - without the need for a full Dev Studio, project, etc?
One big advantage of TMT is that it can be run on a separate screen - so I have DevStudio on one screen, and TMT+TE on another.
Will it still be possible to have the “source” view on one screen, and the “debug” view on another?
Obviously, target is to reach same backtrace decoding capability than TMT.
Yes, and getting traces from them (TMT wasn’t able to do that).
Actually, there is no reset detection: the development mode persistence is saved on the device (i.e. the device stays in development mode even if not connected to DevStudio; it will have to be explicitely set to production mode to resume “normal behaviour”).
This may be an important change in your developer habits, but in our opinion it’s the best way to guarantee it always works:
No way to implement a 100% reliable reset detection mechanism
If the target starts in development mode, you’re absolutelly sure that all traces are sent from the beginning, without any doubt around “Have I enabled the traces quickly enough to get them all?”
Exactly, this is the point of the feature. Among other things, it enables to collect traces in long-terms scenarios including target resets.
Not at the same time and on the same port than DevStudio (like you can do it with current DevStudio versions). But if you close (or don’t open) DevStudio connection, you still can use TMT on the target, or even use DevStudio on one port, and TMT on one other.
We are indeed studying this possibility, since it doesn’t make sense to use the full-over-600MB-with-all-toolchains-IDE just to collect traces. The software architecture is ready for that, and we’ll probably submit you the first beta in this format.
IIRC, I told you about using the Eclipse Window > New Window menu. Unfortunately, this feature is not working with current Target Management implementation, but we’ll take care of making it full functional with the new one.
We’ll provide an option to hide/show the timestamp column.
Any suggestion about the timestamp format?
I think one of the problems with the current “console” is that it’s an extra layer of unknowns in trying to communicate with the device (I think the same applies to the “Expresso” tool?).
There are enough “unknowns” alread - especially for beginners - in just getting a serial connection to a modem; eg,
Correct port
Correct cable
Correct setup
etc…
What is needed is something really minimal just to show that the device is properly connected - without any extra processing, distractions, fancy processing, etc, etc,…
One thing that I find invaluable for this is to have mimic “lights” to show the activity on the actual port lines; eg,
Presumably, that will require a device firmware update?
Indeed - it would need to be very clearly documented!
There would need to be a way (AT Command) to escape - in case a device is “accidentally” left in “development mode” after it’s removed from DevStudio…
This probably also needs to be accessible remotely/programmatically?
Yes, that sounds good; particularly when debugging via USB - where TMT always misses the initial traces due to the time required for the USB to start.
OK, I reformulate: Obviously, target is to reach at least same backtrace decoding capability than TMT.
As the current one, new Target Management implementation will be open-source. Now (and you would say that it’s not a surprise), it’s not properly documented. However it would be a basis to start looking on how to customize or implement a new UI on top of Target Management API.
This is loged; thanks for the suggestions
You’re right, but we need to have a high level access to AT commands in order to implement some other Target Management features. And you’re also right we need a simpler way to easily diagnose what is going wrong when trying to connect to the device.
Actually, we plan to make behave the DevStudio differently according to the device mode:
Development mode: we will have an AT console similar to the existing one
Production mode: a reduced set of functionalities (i.e. AT commands and download), and the AT command console will be as simple as possible in this case, directly plugged on RX and TX serial signals, without any additional layer.
Thanks also for the suggestion about the signals activation “leds”, this can be indeed usefull.
Yes, we are indeed going to add a new AT command in the firmware, allowing to control that.
This means that:
This development mode persistence feature will be available only if you’ve upgraded your firmware to the right version (currently targetted: Software Suite 2.34)
It will be possible to disable “manually” the persisting development mode
Actually it is open source from Eclipse plug-ins development environment.
You have to first download a raw Eclipse SDK (http://www.eclipse.org/downloads/, and download “Eclipse Classic” package)
Then, follow the install instruction from the release note (http://www.wavecom.com/releasenotes/m2mstudio/1.1.2) and choose the feature proposing the Developer studio source code + runtime.
Once installed, you will be able to import in your workspace any of the DevStudio Eclipse plug-ins:
There needs to be a way for the Application to tell that “development mode” is on - so that it can report this if a device “accidentally” gets into the field with the mode left on…
TMT has a bug with ‘&’ (ampersand symbol) in Traces: it causes the next character to be underlined, and the ‘&’ is not displayed (ie, it’s doing what Windows does with menu definitions).