COM port management still needs attention.


#1

Although it is vastly superior to M2MStudio v1, it’s still not 100%.

In particular, when things go wrong - especially with USB.

Once it gets itself confused, it usually can’t be recovered without restarting the Studio - and sometimes the whole PC.

It will often say, “the port is in use by another application” - when it isn’t.

Or the port will not appear in the list - when it should be there.

I sometimes see messages about the “USB Scrutator” (?) having failed.

The persistent Development mode seems to agravate this: if the connection is lost without shutting down properly, the device is left in Development mode; when attempting to re-connect, DS seems to get confused by the incoming traces, etc.

I think some testing needs to be focussed on the behaviour in the face of COM port “problems”:

  • Unexpected removal of the target device
  • Unexpected power-cycling of the target device
  • Unexpected reset of the target device
  • Target device crashing
  • Connecting a target device that is unexpectedly already in Development mode
  • Unexpected removal of USB devices

The automatic backtrace retrieval seems to be rather susceptible to things going awry.
This is a real pain when the target gets into a reset loop:

  1. The target crashes
  2. The device restarts
  3. DS starts trying to retrieve backtraces
  4. The unit crashes again…

#2

To be fair, I should add that the old TMT/Selima arrangement was never 100% - and was apt to get its knickers in a knot and require a system restart…


#3

We’re aware of these USB-related issues, and we know that USB driver is quite not reliable.
As I said in another post, a new USB driver is under development (with the goal to not loose the COM port at Windows system level on target reset), and we’re expected a lot of improvements from it.
Unfortunately, it won’t be ready for 2.1 release, but we’ve a good hope to have something functional within the end of the year (somewhere in Q4).

Concerning the backtraces topic, 2.0 release shouldn’t automatically retrieve backtraces when the device resets, but it’s true that it was the case with 1.2
Are you running the 2.0 release, and do you still observe that behavior?


#4

I mostly still use 1.2…