Specification / Feature List for New Target Management?

Do you have a specification or feature list for the new Target Management?

Would seem like a good idea to review that before you go ahead and implement it, only to have people say “we don’t like that…” or “what happened to ?”

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


Any comment welcome!

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?

The timestamp format in the screenshot uses up a huge amount of screen real-estate!

There needs to be options to control that!

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?

Don’t set you goals too low - there are definitely things in TMT/TE which could be improved!

Excellent! :slight_smile:

Good.

Great.
Even better if the interface could be made “Open” so that we could build custom Trace capture/logging devices or applications…

Oh yes - I think you did! :blush:

I guess that’s why I never used it - and, hence, forgot about it! :unamused:

It needs not just a hide/show option, but also a format option.

Options to provide:

  1. Same as current TMT (ie, just run-time seconds & decimals);
  2. “Unix Time” seconds & (optional) decimals;
  3. hh:mm:ss[.sss]
  4. [yy]yy-MM-dd hh:mm:ss[.sss]
  5. :question:

Maybe provide a “format builder” like Excel, et al… :question:

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,

See: antronics.co.uk/downloads/comled.htm

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.

Yes - that was a real limitation of TMT!

OK, I reformulate: Obviously, target is to reach at least same backtrace decoding capability than TMT. :wink:

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

I didn’t realise that the current one was open source!

Where should I look for the source?

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:

  • Open the Plug-ins view
  • Select the desired plug-in
  • Choose right-click > Import as > Source project

And from there, you have to read Java :wink:

I thought you might say that…

BTW: does that smiley work for you?
It doesn’t work here - see: https://forum.sierrawireless.com/t/smilies-broken/4211/1

No, it’s indeed broken since the forum migration at sierrawireless.com

Just remembered another bug in the current Trace view: handling of the “%p” format…

Yes, this one is logged and planned for fix in this release.

Another one (an improvement required over TMT):

TMT names its trace log files in the form Tracen_ddMMMyyyy.txt; eg,

Trace0_28Jun2010.txt
Trace0_29Jun2010.txt
Trace1_17Jun2010.txt
Trace1_25Jun2010.txt

This is not good because, as you see, the names do not sort into a sensible order!

I think a far better name format would be something like: yyyy-mm-dd_Trace-nn.txt

Thus the above would become:

2010-06-17_Trace-01.txt
2010-06-25_Trace-01.txt
2010-06-28_Trace-00.txt
2010-06-29_Trace-00.txt

Note the use of 2-digit month to ensure that alphabetic & numeric sorting give the same result;

Similarly, always 2 digits for the trace number (maybe 3 - incase anyone takes >100 traces in a day?)

Thanks for the very good suggestion; now added to the backlog :wink:

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).

Do you mean the embedded application?
Isn’t the AT command enough for this case?

Maybe I’m wrong, but I think this is already behaving correctly in the current Target Management traces view (’&’ printed as ‘&’, not as ‘_’)