Target Management Console Problems


#1

1. “Long” commands, or command sequences, are not (always) delivered correctly

eg,

AT+MYLONGCOMMAND parameter1,parameter2,parameter3,parameter4

On hitting , nothing happens - the command is not delivered to the application, and there is no response.
Hitting again doesn’t help.

Sending AT may get an OK response

This also seems to happen during sequences of commands; eg,

AT+CMD1

AT+CMD2 parameter

AT+CMD1parameter1,parameter2

Again, sending AT may get an OK resply, and commands will be accepted again.

2. Spurious Trace output appearing in the Console

This also used to happen in the old TE with TMT.

I think it happens less in DS - but it does still happen.


#2

–> 1.
Do you have a small Open AT application sample reproducing the issue? Did you make the test with TMT to be sure it’s related to DS and not to the target?
Another question: which baud rate are you using?
We’ve observed some AT commands handling issues when baud rate becomes particularly high (460800 and higher).

–> 2.
Clearly a target issue. DS and TMT both display in the console everything which is not correctly encoded in our protocol frames. Spurious characters which appear in the console clearly come from a bad encoding on target side. Will see with the concerned people if they have any clue on this pretty old legacy issue…


#3

I have just seen this problem occurring with the Sound_Demo sample provided with DS.

I am using the sample unaltered, apart from adding the following function to trace what is actually being delivered to the AT Command handlers:

void traceReceivedParas( adl_atCmdPreParser_t * paras )
{
	TRACE(( SD_TRACE_LEVEL, paras->StrData ));
	DUMP (  SD_TRACE_LEVEL, paras->StrData, paras->StrLength+1 );
}

example of use:

void sd_STOP_CmdHandler ( adl_atCmdPreParser_t * paras )
{
    s32 sReturn = OK - 1;

    traceReceivedParas( paras );

    // Switch on CmdType
    switch(paras->Type)

Example command sequence:

Note that the “OK” response appears immediately after the “at+tone=2000” command, but there is a blank line between the “at+tone=3000” command and its “OK” response: this was where the command was not recognised when I hit Enter, so I hit Enter again - and that did give a response.

The Trace is:

Note that the “at+tone=3000” command was delivered to the handler as “at+tone=3”

Not yet

The above was at 115200


#4

Another example

Here, I typed “at+tone=3000” and got no response, so I hit Enter again - and got the ERROR response.

The Trace is:

Here, you can see that the command was delivered as just “at+sto” - so it didn’t even reach the handler!


#5

Thanks for the clues for reproducing. Last questions:

  • what are your FW/Open AT OS/DS versions?
  • Is it a coincidence that the issue occurs only on AT+TONE=3000 command in your given examples?
  • Is it easy to reproduce? (i.e. do we have to send 10 or 1000 commands to expect reproduce it? :wink: )

Thanks.


#6

ATI9 response is:

Yes, I think it’s a coincidence.

It seems that the bug occurs after a certain number of commands have been issued (or, possibly, after a certain number of characters), and it just happens that I’ve used the same sequence - so the bug manifests at the same point.

The quoted sequence is sufficient after starting the application in DS.


#7

Ok, thanks; we’ll have a look to find the root cause of the issue.