SIM800C переодически отключается при работе по TCP Опции

[lolful]

Модем 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

[Aner]

Пробуйте с прошивкой 1418B03SIM800C24

[lolful]

Удалось выяснить, что проблема как-то связана с пинами RI, RTS, CTS или DCD. При их отключении, работа модема нормализовалась. Появилось еще больше вопросов.
При том, что контроль потока отключен (AT+IFC=0,0).
Надо смотреть что на эти пины может выводиться. Однако то, что из-за них модем глючит и перезагружается, почти доказанный факт.

Лог. уровни согласованы, согласно даташиту на SIM800C.

[Aner]

Удалось выяснить, что проблема как-то связана с пинами RI, RTS, CTS или DCD. При их отключении, работа модема нормализовалась. Появилось еще больше вопросов.
При том, что контроль потока отключен (AT+IFC=0,0).
Надо смотреть что на эти пины может выводиться. Однако то, что из-за них модем глючит и перезагружается, почти доказанный факт.

Лог. уровни согласованы, согласно даташиту на SIM800C.

Так что на эти пины у вас подключено и как отключаете?

[lolful]

Отключил, отпаяв резисторы 1 КОм. То есть, сейчас они висят в воздухе.
Схема согласования уровеней из даташита, рисунок 19 для пинов RI, RTS, CTS, DCD, DTR, TX.
Для RX - рисунок 20.
Проц работает от 3.3 В.

Программа проца не должна ничего выводить на соответствующие ноги. И они должны быть в высоком имедансе. Возможно, бутлоадер включает пины на выход и выводит там "0" (низкий импеданс).
По факту на пинах мультиметр показывает 0В.

Копать глубже буду позже - пока есть более приоритетные задачи.

[Aner]

Похоже проблема повторяется в 1001 раз. Эти китайские говно рекомендации детсадовские никто не использует, если более менее серьезный первркурсник или начинающий. Из-за диодов защиты, и дисбаланса напряжений, фантомное питание модулю вы обеспечиваете этими решениями.
Проц питать от 3.0V можете? Если да, то так и делайте. ТОГДА НИКАКИХ РЕЗИСТОРОВ ВООБЩЕ НЕ НУЖНО. Все как на схеме рис 18. Если все же нужно питание (по каким то заморочкам, никому непонятным) 3.3V ставьте нормальные трансляторы уровней, тут на форуме есть несколько рекомендаций. Тогда пролемы пропадут.

[lolful]

Каким образом появится фантомное питание если, во-первых, после делителя из резисторов 1 кОм, 5.6 кОм получается потенциал "1", равный 2.8В, соответствующий лог. уровням модема. Во-вторых, на этих ножках всегда лог. "0"?

[Aner]

Каким образом появится фантомное питание если, во-первых, после делителя из резисторов 1 кОм, 5.6 кОм получается потенциал "1", равный 2.8В, соответствующий лог. уровням модема. Во-вторых, на этих ножках всегда лог. "0"?

.. почитайте посты по питанию SIM900-х, подключению внешних контролеров там все объяснено.

[lolful]

Обратно запаял все резисторы - глюк не появлся... Что-то я упустил. Наверное как-то связано с тем, что сегодня луна полная...