Модем SIM800C с прошивкой 1418B02SIM800C24. При тестировании изделий был найден следующий баг. Примерно через минуту-две после соединения по TCP отключается модем.
Особенности инициализации:
AT+CSCLK=1
AT+DDET=1,200,1,0
AT+CSDH=1
AT+CIPMUX=0
AT+CIPMODE=0
AT+CIPRXGET=1
AT+CIPQSEND=1
Считывание из сокета командой:
AT+CIPRXGET=2,128
+CIPRXGET: 2,20,0
(Data...)
OK
Передача через сокет командой:
AT+CIPSEND=188
> (Data...)
DATA ACCEPT:188
Напряжение питания стабильное 3.8В, ниже 3.6В не падает.
Как выглядит этот баг. Модем инициализируется, подключается к GPRS, подключается к сокету, начинается обмен пакетами (светодиод NETLIGHT мигает 3 раза в секунду). Пока все хоршо.
Как только обмен пакетами становится интенсивнее и трафик возрастает, появляется вероятность, что модем заглючит. Проявляется этот глюк в том, что пин STATUS выдает "0" 3-4 секунды, в это время, AT-команды не выполняются, светодиод гаснет. Затем, STATUS становится в "1", светодиод NETLIGHT начинает мигать как при подаче питания (где-то раз в секунду), в UART выдается 0xFF 0xFF. Затем, примерно через 10 секунд, ситуация может повториться. Через какое-то время модем раздупляется и начинает работать как будто на него только подали питание.
Кроме того, после этой ошибки модем долго не выдает строчку Sms ready (минуты 3), как следствие, не хочет выполнять команду AT+CSDH=1 во время инициализации.
Если короче - то в процессе обмена по TCP модем сам перезагружается и некоторое время глючит (перезагружается снова) и плохо инициализируется.
Simcom'овская утилита catcher.exe в момент глюка в логах пишет, что в модеме произошел fatal error. Но я не могу разобраться в данных catcher'а, так что не заню в чем причина этой ошибки.
Логи инициализации модема, логи catcher'а и дамп памяти модема на я.диске: https://yadi.sk/d/etdh4BoMieGZC
Мои подозрения падают на сочетание настроек режима работы с сокетами: (AT+CIPMUX=0; AT+CIPMODE=0; AT+CIPRXGET=1; AT+CIPQSEND=1)
Может ли кто-либо подсказать как проанализировать логи catcher'а самостоятельно? Потому что времени ждать, пока ответят в Simcom'e на письмо, особо нет.
И сталкивался ли кто-нибудь с таким глюком и как его можно обойти, какие у кого есть идеи что еще можно проверить?
Дополнение. Сначала я думал, что к этому может приводить то, что пишу в закрытый сокет или в сокете переполнятеся буфер. Тогда я перед отправкой и приемом данных выполнял команды CIPACK, CIPSTATUS, CIPRXGET=4 и пр. Но это ни к чему не привело. Перед возникновением глюка все выглядит отлично, типа того:
+CREG: 1,1
+СGREG: 0,1
+CSQ: 22,0
+CIPSTATUS: CONNECT OK
+CIPACK: 1000,1000,0
Прямо перед глюком, если успеть (если повезет), можно отловить +CSQ: 0,0