AT-command processing stopped

Legacy Open AT
1

Hello all,

I’ve unsuccessfully tried to find existing topic of behaviour that I’m experiencing.

Environment:
Module: SL6087 (on Sierra development platform board)
Dev Framework: 2.37
FW: 7.47
OS: 6.37

Basically I’m doing stress test of AT commands interface (adl_atCmdSubscribe). Design plan is to use that link as main communication link with second processor (like RPC link). I’m unable to resolve strange behaviour so any help is welcomed.

After couple of minutes of test (test description below) there is no more responses from UART on which test is run. Not just subscribed commands but all commands (including simple ‘AT’ command).
In order to restore AT functionality I must
a) restart module OR
b) disable/enable port by issuing at+wmfm commands through unaffected port (second UART or USB port)

Test description:

  1. subscribe to test command handler with adl_atCmdSubscribe (see below code)
  2. from external application (for example docklight) send at-test=“123456789012345678901234567890123456789012345678901234567890”
  3. external application resend at-test command from step 2. after each detection of “Finished\r\n”

Interesting observations:
‘Broken’ port is firing unsolicited responses without a problem (not shown in below test). It seems like just AT command processing is affected.

I’ve tried with switching to Production mode in DS, tried to switch off USB and unused UART before test, tried to download release version and exit DS before test… with no new clues…

Can somebody push me in the right direction with this, please?

// Application tasks declaration table
const adl_InitTasks_t adl_InitTasks [] =
{
    { main_task,  DECLARE_CALL_STACK ( 2048 ), "main", 1 },
    { 0, 0, 0, 0 }
};


//
void ATCommandsInterpreter_CmdHandler_Test(adl_atCmdPreParser_t *paras)
{
    switch(paras->Type)
    {
        case ADL_CMD_TYPE_PARA:
        {
       		adl_atSendStdResponsePort ( ADL_AT_RSP, paras->Port, ADL_STR_OK );

		adl_atSendResponsePort ( ADL_AT_UNS, paras->Port, "Finished\r\n" );
        }
        break;
    }

}

void main_task ( void )
{
    adl_atCmdSubscribe("at-test", ATCommandsInterpreter_CmdHandler_Test, ADL_CMD_TYPE_PARA | 0x0011 );
}
2

Hi ivanl,

I’m using AT Command Interface for a long time now and also use it for FW updates or data transfers.
I never had the issue that it locks up. But I assume that some Buffer is filled completely (RX or TX) and the module
can’t process any further. AT+WMFM will flush the buffers and the processing can start again.

I would suggest not to use unsolicited response, because it is of no priority and I have observed that they get delayed under heavy traffic situations.
Here my suggestion (not tried it), use OK/ERROR to detect end of AT command processing:

// Application tasks declaration table
const adl_InitTasks_t adl_InitTasks [] =
{
    { main_task,  DECLARE_CALL_STACK ( 2048 ), "main", 1 },
    { 0, 0, 0, 0 }
};


//
void ATCommandsInterpreter_CmdHandler_Test(adl_atCmdPreParser_t *paras)
{
     adl_atSendResponsePort ( ADL_AT_RSP, paras->Port, "Response\r\n" );
     adl_atSendStdResponsePort ( ADL_AT_RSP, paras->Port, ADL_STR_OK );
}

void main_task ( void )
{
    adl_atCmdSubscribe("at-test", ATCommandsInterpreter_CmdHandler_Test, ADL_CMD_TYPE_PARA | 0x0011 );
}
3

Hi gregorbader,

Thank you for your reply.

I’ve used Q24 module for couple of years but never in such heavy duty scenario so can’t exclude general problem with command processing.

I understand your thinking but my test resends AT command only after receiving unsolicited response so there is no possibility of queuing more requests. Do you think there is some post processing of input/output command queues that are unable to complete due to speed of new commands firing?

I forgot to mention that with shorter AT command parameter (for example at-test=“1234567890”) I was unable to reproduce AT commands interface locking. Maybe it will lock out eventually. I can do overnight test with that.

My system must use unsolicited responses for ‘Module -> second uC’ communication link. I hope there is exact reason for this so I can model my system to ‘behave nice’ to that (possible) limitation.

I will try your suggestion as well as updating SL6087 FW and test with Q24 module.

Any ideas with this issue are highly welcomed.