Поставили прибор с модулем sim900 (B03 ENHANCE) на тестовую нагрузку (SMS, GPRS и т.п) на несколько дней. По логам видно, что модуль пару раз самостоятельно (без команды извне) переходил в ребут, естественно управляющая программа об этом ничего не знала. Кто виноват пока неизвестно, может мощная наводка, может схемотехника, может модуль сбоит. Как достоверно и быстро определить факт перезагрузки модуля. Про Call Ready знаю, но можно ли обойтись без незапрашиваемых ответов?

Варианта 2 пришло в голову сразу:
1) Зафиксировать UART_BAUD_RATE командой "AT+IPR=115200\r" и ловить "RDY\r\n" в случае перезагрузки.
2) "Поднять" какую-то ножку GPIO в "1" командой AT+SGPIO и ловить, когда свалится в "0".

.. а вообще - причину искать

Менять какую-либо настройку (ATS8) не сохраняемую модемом. Периодически её проверять.
Либо использовать строго CMUX aka GSM 07.10 (при сбросе из него вываливается).

Вариант мол "при сбросе из UART придёт особенная строка" не очень-то рабощий по 10001 причине (может прийти в режиме передачи данных или в другой неподходящий момент).

периодически проверять какую-либо настройку не очень-то рабочий, т.к. постоянно нужно дёргать модем проверкой. При этом невозможно нормально уложить в малопотребляющий режим как сам модем, так и MCU.

Правильно всё-таки ловить аппаратные признаки - факт опускания ножки из 1 в 0. По этому событию можно также разбудить управляющий MCU, если он до этого спал.

А почему бы не отслеживать ножку STATUS? Если она соединена к GPIO на которую можно повесить eventhandler, то о выключении модуля можно узнать, если состояние сменилось с "0" на "1". Плюс я бы посмотрел есть ли сообщения типа UNDER-VOLTAGE POWER DOWN, UNDER-VOLTAGE POWER WARNING, OVER-VOLTAGE POWER DOWN, OVER-VOLTAGE POWER WARNING? Если есть, значит модуль перезагружается из-за питания. Но если они(сообщения) не приходят, то не нужно исключать такого варианта, т.к. просадка питания может происходить быстрее чем модуль выдает URC.

Совершенно верно, так правильнее.
Только не с "0" на "1", а обратно

>>>По логам видно, что модуль пару раз самостоятельно (без команды извне) переходил в ребут.

Может все же стоит не костыли городить, а найти причину ?
На недавнем семинаре одни из клиентов после вопросов о зависаниях и сбросах просто ошарашили народ.
У них пару тысяч устройств под управлением ЕАТ, без внешних ребутеров и контроля прекрасно отпахали больше года без единого сбоя.
Любуйтесь - http://ai-grifon.com.ua/index.php/ru/ptsn/transiver-tspti Контроллера нет - всем занимается чипсет SIM900R
На модуле висят - клавиатура (при необходимости), графический I2C индикатор, внешняя SPI память и SPI Ethernet контроллер. Ну и еще кое что для стыка с внешним миром датчиков.

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