Limitations to adl_atCmdSubscribe()on UART?

Legacy Open AT
1

Hello everyone.

My system is build of 2 modules. Module “a” (not a SiWi product) sends information via at commands on the uart to a SL6087 Modul.
An example AT command would be:

AT+MY_TOAST=1

which i´ve subscribed to with the function:

adl_atCmdSubscribe ( "AT+MY_TOAST", CmdHandler_MyToast, ADL_CMD_TYPE_PARA | 0x11 );

This way im having 15 commands which gets send by the other module in a loop, with about 200ms between each command. So i´m sending about 5 commands per second from the other module.
The longest commandString is about 60-80 charakters, the others are normaly < 20.

At the start, the all the CmdHandlers gets called whenever the module sends the particular command (or if you want to see it from the other side: when the SL6087 retrieves it^^)- or when i enter it manually in the remote shell (dev studio).

After (seemingly) random time durancys (which allways seems to be < 10 minutes) the SL6087 stops to handle the commands, which got send by the other module (if i believe the debugger of the other module^^). But when i enter an command manually into the console, it still gets handled…
But as soon as i restart the SL6087 via

at+cfun=1

it starts to handle the commands which got send from the other module again, without causing any “harm” (like a restart) to the other module.

So…Is there some sort of a limitation to sending AT commands via UART (to an SL6087) or is it more likely that something happens on the other module, which currently is just unnoticed or wrong interpreted by me?

2

Remember that AT commands work strictly on a command-response basis; ie, the “client” must not send a new command before it has received the final response to the previous one!

At the speeds you mention, I think you possibly ought to be looking to a different protocol between your modules…?

3

i think you can have a look at what you get on uart. Maybe, you start getting wrong characters within your custom AT command and your module can not execute the command.

4

since i don´t want to rebuild half the programm (which in most parts isn´t written by me), i´ll try to stay at at-commands… but yes, it most likely is not the best protokoll to choice…

the connection is “hard wired”, i can´t just put a pc between the two modules and forward the data, while monitoring them… how can i look into the transmition? Does the Dev Studio have some function in that direction?

5

When you send commands manually from the console, is it on the same UART as the “other module” is sending AT commands on or a different?

I have observed that AT-command processing can stop at random when saving data to flash, and I have to use the +WMFM command (on virtual port or the other UART) to close and re-open the UART that I was receiving commands on in order to get it working again.

6

the module sends on UART1, while i´m on UART2

and i´m neither writing nor reading the flash… but to reopen the UART is an idea i´ll try.

7

reOpening the UART works just fine, even if its just a workaround… :S