Наблюдается странное поведение, когда обмен между SIM900 и микроконтроллером встает. В процессе разбирательств сделали такой трюк, с помощью диодов и одного pull-uр резистора объединили RX и TX по И и вывели на RX-овый вход USB-UART мостика (CP2103). И тоге имеем в гипертерминале протокол обмена модуля и контроллера. Поскольку в основном обмен полудуплексный то все достаточно наглядно. Этим методом изучали, где затыкается.

Так вот, обнаружили что:
1) Затыкается не в определенном конкретно месте, а блуждает по разным командам.
2) С очень высокой вероятностью на сбойной команде видно мусор в терминале, что говорит об одновременной активности RX и TX. Но иногда мусора нет.
3) Остановка обмена выглядит так, мы туда что-то послали (например, AT+CPIN=0000), а в ответ тишина, ну то есть вообще ничего, ни OK, ни ERROR.

Из фактов пока все.

Пока что решили увеличить задержки между командами. И теперь все работает вроде, хотя и медленно.

Но ведь раньше их тоже не то чтобы слали без разбору. Ждали OK или таймаут. А оно все равно умирает. Ну была гипотеза, что нельзя до прихода OK начинать слать следующую команду, и при неправильном таймауте оно может не дожидаться ОК, и слать следующую команду. Но тогда странно другое:
1) Ну и что такого, что команда идет до OK, она же в буфер идет? И будет обработана второй.
2) Мы видели зависание команд, которые в логе вполне чистые, то есть нет наложений на предыдущий ОК.
3) Допустим, что при приеме команды и до выдачи ОК модуль вообще RX выключает. Допустим, что он пропустит начало следующей команды и примет только конец, тогда он должен выдать ERROR. Но вот ERROR мы никогда не видели от него. Получается, что мы как-бы вообще всю команду послали в закрытый RX ему. Странно.

Да, эхо у нас выключено, и падать начинает сильно после его выключения.

Самый первый вопрос - скорость стоит в автоопределении или поставили фиксированую?
Второй - какой уровень единицы при обмене ?

1) Модули не перепрограммировали по части режима скорости, я так понимаю, что они с завода идут в автоопределении. Микроконтроллер им честно отсылает AT при старте до прихода ОК, чтобы автодетектнулись. Я помню, что когда первый раз делал проверку, то на AT эхо приходило, а на at - нет, из чего я заключил, что это автобод так себя ведет, значит он там есть.
2) Уровни такие: RX модуля - 3.34В, TX модуля - 2.89В.

Вообще при более медленном обмене (более редкого темпа выдачи команд) все это живет вполне стабильно, если измерять стабильность в количестве выданных команд.

1. Поставьте фиксированую скорость - на автоопределении бывают чудеса.

2. >>> RX модуля - 3.34В
А сколько допустимо по даташиту ???? Модули еще не выбрасывали с горелым входом ?

1) Ну, а какая связь бодовой скорости и этой проблемы? Что изменится при более редком темпе выдачи команд.
2) Допустимо вроде как 3.1. Но это пока первый образец. Поправим.

Так а причина затыка то в чем?

При автободинге остается небольшое дрожание скорости - оно может влиять на межкомандный интервал.
И кстати рекомендуется не спешить с командами - запрос-ответ-следующая команда.

>>> Ну и что такого, что команда идет до OK, она же в буфер идет? И будет обработана второй.

не обязательно, может быть проигнорирована

>>>Мы видели зависание команд, которые в логе вполне чистые, то есть нет наложений на предыдущий ОК.

при дрожании скорости и завышеных уровнях модуль точно так же может не принять команду
кроме того общий разбег скорости не должен превышать 2%

>>>тогда он должен выдать ERROR. Но вот ERROR мы никогда не видели от него

а если он недопонял команду и ждет ее окончания???

Вобщем приведите уровни в соответствие, поставьте фиксированую скорость и посмотрите ее погрешность со стороны контроллера.
Соблюдение этих трех простых правил практически исключит непонятки.

И еще не забывайте что если прозевали фантомное питание модуля, то как он себя будет вести никто не предскажет.
И самый главный вопрос который я всем задаю - а куда вы спешите так с командами? Зачастую ожидание реакции сети сводит на нет всю спешку.

>>> не обязательно, может быть проигнорирована

То есть, он выключает прием до выдачи ОК или ERROR? Или буферизует ввод?

У нас ошибка бодовой скорости не должна быть более 0.7% для 115200 при выбранном резонаторе.

>>> а если он недопонял команду и ждет ее окончания???
Ну, это возможно было бы при условии, что он вообще отключается и не слушает. В противном случае с чего бы ему не понять, ведь в логе видно, что команда была и альтернативный слушатель ее на 115200 видел.

Уровни поправили. теперь имеем RX = 2.93В, TX = 2.89В.
Кстати, а чего они до 3.3В то не дотянули? Довольно странно, что при рекомендованном питании в 4.1В ограничение по I/O ни то ни се.

на самый главный вопрос ответ простой: никуда мы не спешим. Программистам была поставлена задача, сделать базовую функциональность по отправке команд и ожиданию набора ответов или таймаута (всякие там unsoliticed ответы не в счет). На основе этого делался алгоритм более высокого уровня, который выполнял последовательности таких команд и анализировал ответы. И таймауты вроде были нормальные, во всяком случае тот же код (буквально, тот же исходник, собранный в Visual Studio 2005) нормально работал с внешней отладкой на 115200. А на микрооконтроллере не завелся. Стали разбираться и выяснили, что обмен встает.
Сейчас, чтобы совсем на месте не стоять, пролечили это путем введения задержек между командами. Теоретически, еще могла быть проблема с ожиданием таймаута, если он вываливался раньше ответа. Но программист клянется, что таймауты у него чуть ли не секундные стояли на те команды, для которых OK вылезает быстро. А вот.

Естественно, что работать в режиме одна команда в пол секунды не очень хочется. Но ощущение такое, что если сразу в упор после ОК послать следующую, что можно нарваться на тишину в ответ.

ЗЫ. А что такое "фантомное питание" модуля?

>>>Кстати, а чего они до 3.3В то не дотянули? Довольно странно, что при рекомендованном питании в 4.1В ограничение по I/O ни то ни се.

4.1 вольта питается только усилитель мощности.
Чипсет имеет питания - 0.9 -ядро и порты 2,8 или 1,8 вольта - переключается выводом чипсета VIO поэтому и такие требования к уровням. вопрос этот не к симкому, а к производителям чипсетов. Идеальный вариант - питать контроллер ровно 3.0 вольта.

>>>нормально работал с внешней отладкой на 115200. А на микрооконтроллере не завелся. Стали разбираться и выяснили, что обмен встает.

Думаю что ошибка явно связана или с построением интерфейса или гуляет скорость контроллера.

>>>А что такое "фантомное питание" модуля?

Наличие любых уровней на цифровых входах модуля когда на него подано питание VBAT, но сам модуль еще не включен выводом поверкей.
Ну и соответственно при выключении - сняли уровни - выключили модуль.
Если об этом не позаботиться, то модуль будет жить своей жизнью....

Кстати проверьте чтобы поверкей был через реальный ключ с ОК, а не на ножку контроллера - это тоже иногда к интересным глюкам приводит

Если есть желание можете скинуть кусок схемы - модуль+контроллер - посмотрим на предмет правильности.

Ну в итоге так и сделали, но у нас там от этого питания еще например NAND Flash питается, хотя она вроде как от 2.7В до 3.6. Микроконтроллер от 1.8 до 3.6.
Вообще, конечно, это грабли с надписью "не наступать". 3.3В - довольно распространенное питание I/O. Во всяком случае, можно было бы и сделать уровни терпимыми хотя бы до 3.6В, раз уж все равно на модуле есть питание 4.1В. Обычно затвор входного транзистора держит чуть больше, но защитный диод цепляют к питанию, и горит то в первую очередь именно он а не транзистор. У меня тут была эпопея в другом проекте с LTM2881б у них тоже есть один сигнал ON, который включает модуль, и который диодом зацеплен на питание логики. Причем там питание логики можно сделать и 3 и 5В, но в процессе модификаций мы перекинули питание с 5 на 3.3, а этот вход ON остался на 5В. В итоге получилась довольно интересная статистика. Примерно 30% схем не стали работать, причем разделились пополам: половина не работала по-тихому, а другая страшно грелась. Я по этому поводу сделал такие выводы: в 70% случаев диод разрушился по-тихому и не повредил транзистор. В15% случаев диод оказался хорошим, а его контакты плохими, и все это греется. Еще в 15% случаев диод разрушился и прожег дорожку от вывода к затвору входного транзистора. В итоге внутренний нижний защитный диод держит вход у нуля и схема тихо не включается. Думаю, и здесь что-то похожее будет.



Сейчас пока решили дальше идти, писать основной функционал, потом еще раз вернемся, откатим задержки до минимума. Скорость контроллера у нас определяется кварцем с 10 ppm вообще-то, не гуляет она. Погрешность там около 0.7% максимум. Завтра проверю еще дополнительно осциллографом.



Ну мы вроде же при старте ему еще ресет подаем честный, всякая жизнь должна заново начинаться.



Да, здесь честно стоят два полевика 2N7002.

Одной стабильности мало. В идеале, когда кварц кратен частоте порта UART. Тогда погрешность установки скорости обмена делителем может стать 0%. В противном случае, кроме погрешности изготовления 0.7%, добавляется систематическая погрешность.
Кварц какого номинала вы используете?

Как два? Как же вы их включили?

Начнем с того, что после некоторых команд подача любого символа в буфер до получения ОК отменяет отработку команды, вполне официально. Так что ОК по ним вы можете и не получить.

А вообще - лучше выдерживать какие то разумные паузы между командами. Процессор модуля занят не только перевариванием команд... Сеть его порой тоже нагружает.

>>>>Скорость контроллера у нас определяется кварцем с 10 ppm вообще-то, не гуляет она. Погрешность там около 0.7% максимум.

Не в этом дело. Какой кварц, какой контроллер и какой делитель? Например при кварце 20 мегагерц на той же атмеге нельзя получить достаточную точность на больших скоростях, надо ставить кварц 18.432
Но если у вас точно разбег 0.7%, то копайте в сторону согласования или программы.

>>>Ну мы вроде же при старте ему еще ресет подаем честный, всякая жизнь должна заново начинаться.

Кому ???? Модулю??? Тут вы ошибаетесь - N_RESET не все сбрасывает. Например DSP часть чипсета не сбрасывается.
А если контроллеру - так тоже нужно смотреть на инициализацию потом - если подпитка пошла в модуль, то никакой ресет не поможет.

Запомните как "Отче наш" - на цифровых входах модуля до появления сигнала STATUS ничего быть не должно. Это не обсуждаемо.


Ну и по остальному коллеги тоже правильно Вам подсказывают.

Master of Nature
По поводу кварца. Кварц у нас на 26MГц, начальная точность -- 10 ppm, температурная стабильность в диапазоне -20..+85 -- 10 ppm (эти точности нужны конечно не для UART, а для радиотрансивера МК).
Используется прямой делитель (без прескейлера) 225, что дает погрешность по передаче от -0.4% до +0.3% (общим размахом 0.7%), и примерно удвоенный разброс по приему (точные значения не помню). Но этого хватает с огромным запасом. Когда я писал про погрешность 0.7%, то имел ввиду именно неточность бодового генератора, связанную с дискретностью делителя. Но я несколько ошибся в оценке, вначале полагал, что там обычный генератор с прескейлером на 16 (как было в предыдущих семействах), из чего выходило, что делитель равен 14, и в итоге делитель равен 224, а это, грубо говоря, и дает ошибку в 0.7%. А оказывается, даже точнее. Я бы даже сказал, что при такой ошибке должно железно работать даже при однократной выборке бита, а многие нынешние реализации UART делают ввод бита по трем и более соседним выборкам, что еще повышает надежность. Из чего я делаю вывод, что сам по себе UART как сдвиговый регистр не является причиной затыков. Тем более, повторюсь, что прослушка довольно часто показывает совершенно чистый диалог МК и модуля, в конце которого модуль вдруг раз и не ответил.

По поводу полевиков тоже все просто. Один транзистор стоит на POWER_KEY, второй - на N_RESET. МК обоими умеет рулить, чтобы уж точно привести в чувства модуль.

Velund
Ну, то есть, Вы подтверждаете, что темп подачи команд влияет на адекватность ответов модуля? Осталось теперь разобраться, что значит лучше выдерживать какие то разумные паузы между командами? Существует описание, поясняющее величину пауз? желательно в измеряемых единицах: мкс, мс, с, а не абстрактно "разумных". Я собственно, про это и спрашиваю с самого начала.

CADiLO
Про сброс. Ну вот это тогда уже очередные грабли, только уже без надписи "не наступать". В Hardware Design Guide 2.00, в разделе 4.14, ничего подобного про EXT_RESET не написано. Имеется, правда, примечание, смысл которого сводится к тому, что сброс не гарантирует того, для чего он задуман: привести модуль в чувства и начать снова отвечать на AT-команды.

Power Key, я так понимаю, еще более программно реализованная кнопка?

К сожалению, рубать VBAT невозможно, так как из него потом делаются питания микроконтроллеров.

Во всех нормальных системах внешний сброс работает асинхронно, и его основное применение - отрабатывать старт питания, когда он выдается с супервизора питания. В этом случае никакой "отче наш" не нужен, все эффекты "фантомного питания" убираются нормальным сбросом.

Ладно. Практика - критерий истины. Поглядим, как оно будет себя вести.

>>>В этом случае никакой "отче наш" не нужен, все эффекты "фантомного питания" убираются нормальным сбросом.

Мое дело было обратить Ваше внимание на грабли на которые многие здесь наступали.
Дальше два варианта - прислушаться к рекомендациям и сделать правильно или продолжать отлавливать глюки и ругать модуль.

>>>К сожалению, рубать VBAT невозможно, так как из него потом делаются питания микроконтроллеров.

Еще одно нежелательное решение. Если питаемся от АКБ, то допустимо, а если питание внешнее, то не рекомендую так делать.

1) Ну, я про рекомендацию понял, это вполне можно реализовать. Я высказался в том духе, что если уж получились грабли, то можно было бы и документировать хотя бы внятно. А то получается, что сплошь и рядом какую-то фичу можно реализовать несколькими документированными способами, но если нужна надежность, то делать нужно иначе, про что в документации либо совсем ничего, либо такой туманный намек, что не все способы одинаковы.

2) Питание внешнее от ИБП. Вообще стоит внутренний импульсник, который делает 4.1В из входного напряжения номиналом от 3.5 до 30В. Поэтому в целом прибор можно подключать много к чему. Например, пока что на столе от USB работает. Но штатно будет именно от ИБП. Но исключить на 100%, что заказчик сэкономит на ИБП, я тоже не могу В перспективе, возможно, будем думать, как приделать одну банку Li-ion в качестве местного резервного питания. Но это не очень здорово, так как всякую такую банку обслуживать в перспективе надо, а это усложняет жизнь. Проще свести все к одной сухой свинцовой АКБ в ИБП, где предусмотрена горячая замена.

Относительно рекомендаций, не могли бы Вы конкретно написать, что именно еще не рекомендуется этому модулю делаться.

Паяться "нехорошими" флюсами и отмываться в уз ванне.

А не проще просто ждать ответов на команды? На локальные команды - ОК и прочее возвращает моментально. А "эфирные" - в любом случае ждать, хочете вы этого или нет.
Не надо никаких задержек. Работайте так, как будто вместо контроллера - человек работающий через гипертерминал. Выигрыш во времени всё равно мизерный. Есть рекомендации на некоторые команды - CIICR например, - где надо и минуту ждать. Регистрация в сети - тоже не меньше минуты ожидания.

Так я же вроде бы написал, что мы ждем ответов и посылаем следующее после приема ОК или ERROR. Но вот уперлись в то, что иногда это почему-то останавливается. Я пытаюсь разобраться, в чем дело. Как человек оно вроде работает, а вот как автомат оно гораздо быстрее в него команды пихать может. Меня даже не напрягает подождать чуть больше в командах конфигурации, я не хочу двух вещей:
1) чтобы была очень низкая скорость передачи данных через инет (по сранению с эфирной скоростью).
2) чтобы вся эта стейт-машина могла долго жить без зависаний, а в редких случаях лечилась вочдогом с переинициализацией, что в целом не влияло бы на характеристики производительности и доступности.

А кто виснет-то SIM900 или управляющий МК?

Не, МК ничего такой, довольно живучий, даже без вочдога. Хотя вочдог в нем тоже есть. Я имел ввиду именно зависание управляющего потока, который рулит модулем GSM.

Баудрейт поставте фиксированный и кварц "чётный".
Кстати а перед переходом в прозрачный режим сменить скорость не резон? Я не пробовал, но по идее то работать должно.
Надо проверить.

AT+IPR на лету работает.
Вот только OK на него ждать не стоит.
Хотя проверял я это только в ручном режиме. В автомате такого не делал, не приходилось.
Да и с затыками такими что-то не сталкивался....

Если с автоопределения на фиксированую - то на лету без проблем.
А вот с фиксированой на другую фиксированую....

Вобщем там так - если не уходить ниже 9600 - то туда-сюда скорость меняется нормально
Если уйти на 2400 или ниже, а потом вернуться назад на 115200, то может с первого разу не перейти - но правда даст ERROR

А что он у вас один?
Да и как бы не зависание это, а скорей ожидание окончания стадии GSM - ничего не поделать.

Не понял, зачем менять скорость?

Артем
Ну проблема в том, что у модуля не очень то унифицирована система ответов. Кроме простых ОК и ERROR, бывают еще всякие ответы unsolicited, причем они не обязательно с + начинаются, не обязательно вызваны действиями, которые мы до этого программировали. В итоге все это приводит к тому, что нет никакой гарантии, что тот автомат, который у нас работает, не уйдет в какое-нибудь нелепое ожидание. Например, ждем OK, а пришло уведомление об СМС. Послали AT+CIPSTART..., в ответ получаем ERROR, собираемся все заново начинать, но потом через какое-то время "0,ALREADY CONNECTED".

В общем, хочется, чтобы во всем этом многообразии ответов система не ушла в бесконечный цикл долбежки в закрытую дверь, а планомерно откатывалась на более высокий уровень повторной инициализации. И чтобы программа при этом не стала занимать больше, чем вся память МК...

Эээээ...А тайминги и попытки ввести никак?
Ну там 10 раз с интервалом в 5 секунд проверит AT+CREG?

Или если не получаете CONNECT - перезапустить сессию?
-------
Анализируйте только то, что вам надо! А отключение питания вы зря не ввели. 100% придётся грейдить плату.

>>>>Например, ждем OK, а пришло уведомление об СМС. Послали AT+CIPSTART..., в ответ получаем ERROR, собираемся все заново начинать, но потом через какое-то время "0,ALREADY CONNECTED".

Ну это не самое худшее, и решаемо - думаю что все здесь с таким сталкивались на разных модулях, это особенности работы с GSM.
Хуже когда добавляется то что у разных операторов поведение может быть разное, затем в разных регионах у одного оператора, затем еще фишки операторов с отступлениями в карточках от стандарта.......

Ну а по поводу обмена вернусь к одной из прозвучавших ранее фраз:

"И таймауты вроде были нормальные, во всяком случае тот же код (буквально, тот же исходник, собранный в Visual Studio 2005) нормально работал с внешней отладкой на 115200. А на микрооконтроллере не завелся. Стали разбираться и выяснили, что обмен встает."

Если с отладкой с компа затыков не было, то копать однозначно стыковку и скорость.
Кстати еще момент - плата помыта хорошо? Флюса под модулем не осталось? Конденсатор на VRTC не забыли повесить?