Есть ли команда или последовательность команд, которая приведет к тому, что модем перезагрузится?
Замечаю, что модем время от времени (раз в несколько дней) начитает "тупить" и если его перезагрузить, то все норм. становится.

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

Полностью согласен.
Но перезагрузить можно по AT+CFUN=1,1

Это не перезагрузка - только перерегистрируется в сети. Если зависла Baseband или RF часть, то поможет.
А если вешается управляющий кусок чипсета или DSP, то.... полный рестарт снятием питания.

Наверное сотое обсуждение этого вопроса. Ставят же, ну почти все, управляемый ключик по питанию после импульсника на 4,2 Вольта. И ЧЁ? Хотим и тут сэкономить? Наверное тот кто сэкономил, теперь задаются этим вопросом ... как перегрузить по питанию Sim900 с помощью AT команды?

Да ясно дело, уже 500й раз такой вопрос, и симкому уже давно известно, но так и влом видимо сделать такую простую команду...

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

Не защищаю тех, кто криворуко разводит платы или экономит на питании, но команда бы не помешала...

А команду кто исполнять будет, если софтина внутри повисла? Или нужно внутрь ещё и какой-нить PIC10 впихнуть в параллель на UART, чтобы он персонально Вашу команду обрабатывал? Это утопия-с. Куда проще или взять управляемый отдельным входом преобразователь (по-моему, сейчас сложнее найти неуправляемый), или всё тот же пресловутый ключ на полевике...

Вы что тоже из тех, кто не догоняет? ... блин вот аналогия -> Лампочка тумблер. Включил, выключил. Никакого там проца, софта. Чипы так же устроены, ничего они не знают о софте, ОС и криворуких и тд. Вот и придумывайте AT команду для выключения лампочки. С линуксом, rtos-ом или др ОС. И что получится?

Симком в свое время привел чудный пример на подобный вопрос.

"Возьмите зависшую мобилку и полностью сбросьте ее или включите/выключите не нажимая кнопочки включения или не вынимая аккумулятор.
Что, не получилось???? Так вот пока производители чипсетов такую функцию не сделают, то и мобилки и модули уметь подобное не будут"

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

Вы программы писали когда-нибудь, под "чистое" железо?? Если нет, то скажу по "большому секрету" , что обработчик УАРТА как правило всегда на прерывании висит, там простая логика, есть заранее определенный вектор и железка просто передает туда управление, а подвисает, как правило, основная прога или менеджер задач, который, кстати, если правильно написана прога, должен сам ресетится сторожевым таймером. Так вот, о чем я... Этот обработчик, может отследить команду ребута и остановить пересброс ватчдога и все. Конечно, на все 100% не решит проблему, но на 99 в самый аккурат

А если б хардварный ресет еще вывели наружу...

А парсер у Вас тоже в прерывании? И не средствами ли оси парсер получает право раскопать пакет?.. "По секрету" напомню Вам поучительные слова: "Гладко было на бумаге, да забыли про овраги"

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

Давайте начнем с того что приоритеты раздает OS которая там крутится. Например в SIM900 - Philis RTK-E OS. Наивысший приоритет имеет GSM стек.
Это все штука лицензионная, полученая от производителя чипсета и менять ее категорически запрещено.
Все что пишет SIMCOM это уже основано на тех таймингах которые выделяет OS и сделать там програмную перезагрузку ну никак не получится.

Поэтому все хотелки подобного плана следует направлять не в сторону производителей модулей, а в сторону производителей чипсетов и держателей лицензий на встроенные OS.

Ну и далее - допустим теоретически что такая команда есть. И приоритет максимальный и все такое.....
Но при зависании модуля съехала крыша у PMU и порты оказались отключенными или не запитаными по Vio. Кстати абсолютно реальная ситуация......

Вопрос - каким образом вы дадите команду на перезагрузку?????

Поэтому не морочим голову - сказано аппаратно, значит аппаратно.

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

Полностью согласен. Но согласитесь, допустим я напишу в филипс или куда там еще, что нужно сделать то-то и там-то... С вероятностью 99.9999% меня пошлют на хутор, ловить бабочек, но если это сделает симком - тут уже другой вопрос...





Ну тут-то как раз все просто - сработает сторожевой таймер, если он есть конечно в данном чипсете

>>>Ну тут-то как раз все просто - сработает сторожевой таймер, если он есть конечно в данном чипсете
А он то откуда будет об этом знать???? Или кто поручится за то что он останется тоже в работе?
Это надо закладывать с нуля создавая чипсет. А подобное усложнение и нафиг никому не нужно.

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

Если бы все было так просто, то наверное кто-то бы такое сделал, там не дурнее вас инженеры работают.

Что Вы знаете о программной обработке WDT? Вы уверены, что он там обрабатывается по всей строгости? Что там нет мест с безусловным сбросом, отключением?.. Что там нет процессов, которые сами могут сбрасывать WDT и при этом могут зациклиться?..

"Ну тут-то как раз все просто" - куда уж проще. Напишите сами SDK и осчастливьте мир! Пусть всё будет без багов и с программным сбросом! Хотя зачем он тогда тут?..

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

ЗЫ. И да, от себя скажу, если вижу в своих прогах хоть небольшую вероятность сбоя или уязвимость - стараюсь ее устранить...

Ага. Сферического коня в вакууме имеем. Думаю, даже инженеры SIMCOM'а не знают всех тонкостей работы оси, куда уж нам. Вам же дали дельный совет: расслабьтесь и воспользуйтесь возможностями аппаратного сброса. Если Вам, конечно, нужен результат, а не "дискуссии" на тему оного.

Шашкой махнули и все....
С GSM такой номер не прокатит - иначе при такой организации получите вечный сброс.

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

Есть куча операторозависимых моментов когда кажется что все - висим, а на самом деле оператор превысил таймауты из-за нагрузки и ответил не через 5 секунд, а через 50.

И почитайте чуть углубленнее о работе GSM стека и таких предложений больше не появится.

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

Wow!
Вот это фидбэка навилило, всем спасибо.

Управлять питанием умеем, но это я рассматриваю как крайний вариант. Вот и интересно стало, что если есть команда.

Вот - очень точно сказано про "нажимая кнопочки включения" - мне вот интересно - а почему нельзя
(невозможно?) делать полноценный рестарт (сброс и т.п.) не "передергивая" питание (аналогично - вынуть и вставить обратно акумулятор в телефоне),
а используя для этого вывод "PWRKEY" (выкл/вкл) (кнопочка в телефоне) - или это опять скажите глупость?
Даже в одном из документов от производителя GSM-модемов заметил рекомендацию про сброс модема "передергиванием" питания.
Ведь в тех же МК мы не "передергиваем" постоянно питание.
Кстати сами пока всегда делаем пересброс именно выкл/вкл питания - заметили, что не всегда
можно обойтись для этого, используя штатно вывод "PWRKEY".
Заранее спасибо за профессиональный ответ.

PS Может сброс "передергиванием" питания подсмотрен у ПК? Там тоже иногда приходится питанием все решать - волшебная кнопочка Reset не помогает,
не говоря уж про CTRL+Alt+Del



Вот и я примерно об этом и спрашиваю



Ну, вот же - в яблочко - "сказано аппаратно, значит аппаратно" - поясните почему нельзя это сделать именно "аппаратно" - управляя выводом PWRKEY ?

Никакой иронии - может все просто - просветите, пожалуйста доргие гуру и прочие, кто это хорошо понимает.

Ведь в МК это можно делать - через соответствующий вход Reset - даже когда WatchDog "завис" (неправильно написан и т.п.).

Должен вас огорчить, что даже с МК не все так хорошо, точнее, не со всеми МК.
Есть разные идеологии, которые витают в умах и разработчиков МК.

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

А вот другой пример: Тексаковский MSP430 - замечательный МК с Фон-Неймановской архитектурой, но заточенный на минимальное потребление.
Его разработчики одержимы обеспечить максимальную конфигурируемость всего, что в нем есть. Поэтому там программно можно выключать вочдог, переключать ногу рестарта на функцию прервания и т.д и т.п. Получается, что ни делай, а есть программная возможность подвесить МК намертво, когда помогает только Power-On-Reset
Поэтому в одной фирме, где мне приходится применять MSP430 по историческим причинам в приборам с батарейным питанием, приходится применять внешний аппаратный триггер для вкл/выкл прибора методом снятия питания с МК. Никакими другими способами побороть иногда случающиеся мертвые подвисы не удалось. (Приборы герметичные, у потребителя необслуживаемые).

Так что я думаю, что в недрах SIM900 тоже есть подобные звери, которые позволяют себя программно подвесить. А если это возможно теоретически, то точно когда нибудь произойдет.

Огорчу, ибо тут все не так просто, в модемах, при выключении питания или рестарте запускаются процедуры корректного завершения (по возможности) GSM стека, плюс еще сохранение параметров во флешку и т.п. Если долбануть им аппаратным сбросом, то все это не будет выполнено. Единственное, что я туда бы добавил, так это как в компах - даешь импульс 1 сек - и, если модуль работает корректно, то он сам вырубается, сохраняет все, что нужно... А если "висит" - тогда держишь 4-5 сек и аппаратный сброс.

Помню давно занимался с gprs модемом от Enfora. Там подобные "глупости" были заявлены в функциях модуля. И вроде как даже работали.


это нонсенс какой-то: устройство находится в неадекватном состоянии, все возможные способы вывода устройства из этого состояния, заложенные в ПО не сработали. С какой целью в таком состоянии сохранять настройки и корректно завершать работу?

Согласен! Тоже любим PICи - аж с 1996 года. Сейчас планируем осваивать STM - посмотрим, как там будет




Да, знаю про эти процедуры. Но ведь нам предлагают "передергивать" питание - а это как раз и не даст выполнить эти самые процедуры.
Вот остальное - интересная мысль. Вот я и спрашиваю уважаемого CADiLO - можно так корректно через "кнопочку" (читай ногу PWRKEY) сделать корректный рестарт,
такой же, когда мы выключаем свои телефоны-смартфоны этой самой "кнопочкой", а не вынимая аккумулятор.
Дождемся ответа.

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

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

А при прочих нормальных условиях правильный алгоритм сброса будет следующий:

Поверкей на 2 секунды на GND, отпустить, ждать до 8 секунд. (До пропадания STATUS)
Если отключения не произошло, то через 8 секунд - повторить.
Если и после этого не отключился, то снять питание с VBAT.

Повторное включение через 2-3 секунды. Хотя я бы включал секунд через 10, особенно если повисло на GPRS сессии.

Теперь о том почему 8 секунд.
Это рекомендуемое время таймаута для рассыпания GPRS сессии и разрегистрации модуля из сети.
Хотя некоторые операторы не придерживаются и ставят больший таймаут.
Если модуль не был в GPRS, тогда это время около 2 секунд.

RESET - конденсатор 0.1мкф на GND и забыть про него.

Насколько мне известно у большинства смартфонов нет доступа к аккумулятору вне сервиса. И не виснут они почему-то...

Дык в отличии от обычных чипсетов в смартах GSM/3G стек на отдельном проце крутится (даже если этот проц физически в одном чипсете с основным).
Полистайте структуру хотя бы Snapdragon, там четыре ядра ARM Cortex A53 (1.7 ГГц) + четыре ядра ARM Cortex A53 (1 ГГц) + DSP baseband + GPU
Грубо говоря одна часть для приложений, вторая для эфирных делов. И PMU основного проца умеет погасить второй снятием питания и запустить снова.

Ну хотя бы вот Q508250
http://files.tested.com/photos/2012/03/16/...snapdragon4.png

В обычных же чипсетах стек это часть времени основного проца и если он виснет то виснет все.

А на предмет "не виснут" - приезжайте в гости, покажу как чудесно виснут
Или погуляйте по Харькову - в городе есть несколько "черных дыр" где RSSI зашкаливает и висяк.
После выхода из такой зоны только АКК передергивать. Внятного объяснения этому мы пока не нашли.

Ну вот опять текста много и все мимо ( с моей точки зрения ). Какая разница один проц или несколько? А если повиснет главный проц?
Что такое стэк? Это обычная программа. И если она написана без ошибок (ошибки "вылизаны") то она не зависнет. А если программа главного проц написана с ошибками, то главный проц зависнет и не сможет перезапустить GSM ный проц.
Итого: "Зависание" модуля - косяк производителя модуля, и ничей более!

>>>Что такое стэк? Это обычная программа. И если она написана без ошибок (ошибки "вылизаны") то она не зависнет.

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

Да и сам алгоритм GSM к сожалению несовершенен (в 3G уже получше) - там есть моменты гарантировано ведущие к зависанию.
Классический пример - пропадание сигнала в предответном состоянии. Например вам позвонили а вы зашли в метро где сигнал пропал.
Если этот момент четко совпадет, то.... Даже после восстановления соединения стек ждет ответа от базы, которая давно уже сбросила процесс.
Все - висим.
Покопайтесь в инете - это все уже давно описано - полностью избавится от зависаний в GSM сетях НЕВОЗМОЖНО.

>>>Что такое стэк? Это обычная программа. И если она написана без ошибок (ошибки "вылизаны") то она не зависнет.

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

Да и сам алгоритм GSM к сожалению несовершенен (в 3G уже получше) - там есть моменты гарантировано ведущие к зависанию.
Классический пример - пропадание сигнала в предответном состоянии. Например вам позвонили а вы зашли в метро где сигнал пропал.
Если этот момент четко совпадет, то.... Даже после восстановления соединения стек ждет ответа от базы, которая давно уже сбросила процесс.
Все - висим.
Покопайтесь в инете - это все уже давно описано - полностью избавится от зависаний в GSM сетях НЕВОЗМОЖНО.

>>>Итого: "Зависание" модуля - косяк производителя модуля, и ничей более!

"Самоуверенность - мать всех ошибок"
(с) «В осаде 2: Темная территория»

А зачем стек ждет ответа неограниченное количество времени? Ограничиваем время ожидания и ушли от этой проблеммы.

Возможно, возможно... Невозможно избавиться от пропадания связи, это да, а от зависаний модема можно.

Про "не виснут" расскажите своей бабушке. Samsung Galaxy S3 явно не знает о Вашем мнении и ведёт себя совершенно непростительно. Притом что не серый, после Ростеста. Вообще, ни одного телефона у меня не было, который бы не вис. Если отдельным индивидам везёт по жизни покупать исключительно стабильные телефоны - это скорее дар. Простым смертным это не грозит.

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

>>>А зачем стек ждет ответа неограниченное количество времени? Ограничиваем время ожидания и ушли от этой проблеммы.

А это уже вопрос даже не к производителям модулей, а к лицензиантам стека - почему такой алгоритм сделан.
Причем это наблюдается у всех, я первый раз столкнулся с таким еще на старичках - GR47.

Понимаю что глупо и неудобно, однако на сегодня никто менять алгоритмы не будет.

Тут ты не прав. Вопрос именно к производителю модуля. А он уже если сочтет нужным пусть его задает кому угодно. Я сильно сомневаюсь, что стандарт заставляет ждать неограниченное время. А следовательно это именно КОСЯК. А чей это косяк пускай решает производитель модулей.

Производитель знает чей косяк - дальше что???
Менять лицензионный стек он права не имеет - вне зависимости КТО делает модули SIMCOM или побрендовее.
А если полезет туда то отгребет штрафы и лишение лицензии.
На фоне сотен тысяч, а то и миллионов изделий процент возможного зависания просто списывается на допустимую погрешность.
Ну а если есть желание побороться, так пошлют вас к тому кто является владельцем лицензии и кто имеет право менять эту часть софта.
Там и высказывайте претензии. Интересно - хотя бы отписку пришлют ?