Наблюдаю такой эффект: в режиме TCP при посылке через AT+CIPSEND=size модем иногда наглухо бросает CTS, прекращает принимать команды (даже если игнорировать CTS) и лечится только перезапуском по питанию.

Эффект вероятностный и зависит от длины пакета данных, причем даже не в байтах, а от времени его передачи из контроллера. Например, на 57600 "критический" размер порядка 320 байт, а на 115200 - около 700. На 57600 пакет в 512 байт уже не передается практически никогда, 256 - не удалось поймать на зависании (вероятность маленькая?), а 320-384 раз на раз не приходится.

Вижу на осциллографе, что после команды CIPSEND модем опускает CTS примерно через 100 мс
после начала передачи данных, и это время, похоже, не зависит от размера данных. Собственно, пересылка через UART к этому времени уже закончена.
Потом в норме через несколько десятков мс (после передачи в GSM?) CTS возвращается
обратно. А если зависло - не возвращается.

Это баг в прошивке или я что-то делаю не так?

1008B14SIM300D32_SST34HF3284

первый вопрос - с питанием всё нормально?

а при подаче ат команды какой размер данных указывали?

Тот, который я называю "длиной пакета" в исходном посте. То есть переменный, собственно о нем и речь.

Дальнейшие эксперименты показали, что при скорости порта 19200 эффект не наблюдается вообще, линия CTS не переходит в неактивное состояние даже кратковременно. Начиная с 28800 как будто бы меняется логика работы модема:
1) примерно через 100 мс после начала посылки CIPSEND модем бросает CTS
далее одно из двух:
2a) через время, на вид пропорциональное размеру посылки, CTS возвращается в активное состояние.
2b) CTS остается неактивным и модем перестает принимать команды до отключения питания.

Причем вероятность зависания зависит от длины посылки и скорости порта: я бы сказал, от заполнения передачей данных интервала в ~100мс до сброса CTS. Так, на 28800 при CIPSEND=256 зависнуть не удалось, а при 272 виснет в 3 случаях из 10 (дальше больше). На 38400, соответственно, критический размер около 320-336 байт. На 115200 - порядка 700-750.
Бросается в глаза, что модем переводит CTS в неактивное состояние не во время приема данных (как было бы логично по смыслу CTS), а - с точки зрения UART - на ровном месте. Команда-то уже принята, контроллер сидит себе и ждет ответа SEND OK...

На осциллографе это выглядит примерно так:
1. Не зависло
Нажмите для просмотра прикрепленного файла
2. Зависло
Нажмите для просмотра прикрепленного файла

А вот на 19200 хоть все 1024 байта посылай - эффект отсутствует.

Но, как я писал, связь нечеткая: бывает, что конец передачи от м/к в модем ближе к моменту опускания CTS, и не виснет, а в другой раз дальше - и виснет. Как будто бы команда CIPSEND вместе с указанным количеством данных должна уложиться в "случайный" интервал времени, мат. ожидание которого немного меньше 100 мс.




По питанию стоит персональный LM2576. Коллега специально бился, чтобы шум при передаче не выходил за паспортные границы.
Какие-то помехи, конечно, есть но см. ответ skaarj - питанием трудно объяснить отличия в поведении при смене скорости порта и размера пакета. Просмотр VBAT вокруг момента зависания никаких красивых синхронных просадок не выявил...

Проблема побеждена неожиданным образом: после AT+CIPSEND=size<CR> нужно делать паузу или ждать приглашения (AT+CIPSPRT=1).

У меня же было AT+CIPSPRT=0 и команда + данные писались подряд (AT+CIPSEND=size<CR>DATA...).

Мда уж... Что лишний раз подтверждает необходимость тщательного прочтения документации!

Китайцы видимо чего-то не доработали...
Я без всякого приглашения данные посылаю только на +СMGW и прочее. Ровно как написано в мануале.

Если бы! В документации написано, что приглашение можно отключать (AT+CIPSPRT=0) и ничего не сказано про паузу. Никаких ограничений при работе без приглашения я не нашел.

"Открытие" было вообще случайным: я стал повторять ситуацию вручную в терминале через copy/paste и скопировал в терминал отдельно команду AT+CIPSEND=1024<CR>, отдельно данные (1024 буквы 'X') - не зависло. Тут-то меня осенило Взял, скопировал все вместе одним Ctrl+V - зависло...

Странно, но у меня стоит AT+CIPSPRT=1 и приглашение не приходит. Модем SIM508.

Эх. Я же сказал, что китайцы видимо чего-то не доработали....
В описании команды +CIPSEND нет никаких намеков, о том, что приглашение можно не ждать и его может не быть. С такими вещами надо быть внимательней, чтобы потом не тратить время впустую на поиск "глюков"

Решил не плодить темы. Опишу косяк, на который напоролся. Условия такие: 1008B14SIM300D32_SST34HF3284, включен аппаратный CTS/RTS, скорость порта 115200, отправляю TCP данные с помощью ATCIPSEND; приходит ответ, например "+IPD1350: ..."; и начинают идти данные. Так вот, если надолго активировать RTS пока все данные от TCP стека еще не пришли - модем может зависнуть (хотя новые TCP данные в модем больше не приходят 100%, TCP соединение тоже сервером не обрывается.) Обрывает ли соединение модем - не знаю. Светодиод мигает. Модем выходит из этого состояния только после отключения питания.
Ускорил процедуру обработки - виснуть перестал, хотя RTS тоже периодически включается. Если исключить включение RTS или увеличить размер буфера, проблема также пропадает.
В общем - проблема решаемая, у меня вылезла когда специально тестировал на маленьком буфере. Но иметь в виду стоит.