Модуль работает как сервер, т.е. ждёт соединения и отвечает на запросы. Обычно обмен идёт так:

Код
16:33:46.265> AT^SISW=2,15
16:33:46.265>
16:33:46.265>
16:33:46.265> ^SISW: 2, 15, 15
16:33:46.265>
16:33:46.453>
16:33:46.453>
16:33:46.515>
16:33:46.515>
16:33:46.515> OK
16:33:46.515>
16:33:46.515>
16:33:46.515>
16:33:46.515> ^SISW: 2, 1
16:33:46.515>


Однако периодически происходит следующее:

Код
16:33:58.765> AT^SISW=2,25
16:33:59.515>
16:33:59.515>
16:33:59.515> ^SISW: 2, 25, 25
16:33:59.515>
16:34:54.703>
16:34:54.703>
16:34:54.703>
16:34:54.703>
16:34:54.703> OK
16:34:54.703>
16:34:54.703>
16:34:54.703>
16:34:54.703> ^SIS: 0, 1, 3
16:34:54.703>
16:34:54.703>
16:34:54.703>
16:34:54.765> ^SIS: 0, 1, 4
16:34:54.765>
16:34:54.765>
16:34:54.765>
16:34:54.765> ^SIS: 0, 1, 5
16:34:54.765>
16:34:54.765>
16:34:54.765>
16:34:54.765> ^SISW: 2, 1
16:34:54.765>


Видно, что после запроса данных модуль висит почти минуту. Данные никуда не уходят. На команды он в это время не реагирует. Потом вываливает кучу URC - клиенты пытаются соединяться каждые 20 сек. В результате все слоты забиты и приходиться его перезапускать.

Нашел это:

Цитата
During repeated calls of AT^SISR or AT^SISW it is possible that
the corresponding URC for the last read or write request is
received before the AT command response. This could lead to
misinterpretation.

To avoid the problem an application should always wait for the
appropriate “^SISR:x,1” URC or “^SISW:x,1” URC indicating that
data can be written. Alternatively it is possible to switch to polling
mode, thereby deactivating URCs for all TCP/IP AT commands
(AT^SCFG; parameter "Tcp/WithURCs”).


^SISR у меня и так обрабатывается асинхронно. А пулить ой как неохота. К тому же ничего не сказано про зависание.

Может кто сталкивался? Дело ещё в том, что порядка нескольких сотен шт. работают нормально. Только недавно началось - второй такой вижу.