Через 2-3 года стали умирать модули MC52i. При включении выдают на скорости 57600 следующую строку EXIT: 740F 08 00 EEFULL. Сдохло уже 3 шт. Все стояли на разных объектах. Все в модемах NOVACOM RUS-55iT.
В разное время было в общей сложности приобретено 55 модемов, так что 3 это приличный процент. Причем как-то странно несколько лет работали а тут один за другим.

Сообщение отредактировал viakon - Feb 7 2013, 15:29

Факторинг, однако!..

В нашем случае ограничение срока службы? Дык маловато 3 года-то.

EXIT: 740F Delete Instance
На сименсовских мобилках лечение прогревом или заменой процессора.
Банальное отваливание ножек чипа. Коды ошибок можно у ремонтников на сайтах накопать.
Как ни странно но старая немецкая педантичность тут сыграла на руку - многое совпадает не только между сериями мобилок но и с модулями.

Eсли погуглить, то не такое уж редкое явление особенно как Cименс продаваться начал по частям....

http://www.automation.siemens.com/WW/forum...amp;Language=en

"We have mc39i gsm modules and most of them send the same " EXIT: 740F 08 00 EEFULL" message right after i turn on the modules using ignition line. Also all the modules which send this message do not respond to any AT command i sent. I search through the datasheets and internet and didn't find anything related to this problem. Does anyone experienced this kind of issue? Thanks in Advance."

Посмотрите тут, может пригодится

http://www.scritube.com/limba/rusa/SIEMENS2411111610.php

Сдох четвертый. Это на непропаи уже не похоже.

Вот такой ответ (через Евромобайл) я получил в итоге.

Hello,

such EXITs indicate problems with Flash memory - it might happen under certain circumstances when module is quickly restarted/power off/on without waiting to save modules settings. Plase never power down module using power switch before using the SMSO command, also please avoid having unstable VBATT during power up. Unstable VBATT may cause power loses during initial procedure and cause problems with internal memory. Also while switching off module always wait for the URC SHUTDOWN before unplugging power. Module needs some time to write NV setting before switching off, and if module is powered down during that procedure it may cause flash problems.

The modules can be repaired in our service - if modules have warranty please issue the RMA procedure.

Best regards,
Pawel Prociow



Cinterion Wireless Modules GmbH
St.-Martin-Str. 60
81541 Munich, Germany

Несколько лет назад я отказался от использования SIM508 по аналогичным причинам (слетала прошивка). Но те можно было перепрошить.
Ну когда до производителей дойдет, что на объекте по всякому бывает и далеко не всегда можно отключить модуль корректно. Вы вообще видели чтоб виндовз подавал команду на отключение модема? В лине то такое можно скриптами сделать. То есть в модемах их по идее вообще нельзя использовать, т.к. некому будет их корректно отключать.
Теперь основной вопрос подвержены ли BGS2 этой болезни? Будет время поставлю один модуль на циклическое дергание питания.
Вопрос к сообществу: отрубать питание лучше после регистрации в сети или дождаться соединения по GPRS? В каком случае теоретически модуль более подвержен сбоям?

>>>Вы вообще видели чтоб виндовз подавал команду на отключение модема?

Неоднократно сталкивался с 3G свистками со слетевшей прошивкой. Причина - просто на ходу выдернули из USB.

Теперь вернусь к
>>>Несколько лет назад я отказался от использования SIM508 по аналогичным причинам (слетала прошивка).

Аварийный слет прошивок пришелся на момент смены памяти в SIM300D и как раз на 13 версию. Начиная с 14 это пофиксили.
В остальных модулях это было в основном при фантомном питании. Процент слета при отключении питания был ничтожно мал.
Вы уверены что у вас нет фантомки и слеты произошли при дергании питания?

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

>>>Теперь основной вопрос подвержены ли BGS2 этой болезни? Будет время поставлю один модуль на циклическое дергание питания

Разделю вопрос

1. Сбоям при фантомном питании подвержены многие модули разных производителей. И у Telit и у Cinterion в доках есть замечание по этому поводу - при отключеном модуле на ножки не подавать сигналы.

2. Просто дергать питание нет смысла - трудно поймать момент перезаписи, да еще чтобы так красиво слетело. SIM900 подвергали подобному тестированию. 5 модулей в разных режимах аварийно отключали.
Трое суток крутили. Не слетели гады. И тем не менее я не исключу того что это МОЖЕТ произойти. И может произойти у ЛЮБОГО производителя. Поэтому корректность в работе и не экономьте на том что может принести пользу.
На корретное отключение нужно МАКСИМУМ 10 секунд. Многие регламентируют 8, но 2 секунды запаса роли не сыграют. Это при закрытии сессии и выходе из GPRS. В голосовом режиме 2-3 секунды на выключение.
Достаточно аккумулятора 950 ма/Ч с разрядом 2С. Конденсаторы это время не вытянут. 2-3 бакса аккумулятор + 1 на зарядное с обвязкой. Это как минимум в три раза дешевле нового модуля.
Сразу отвечу - почему емкость аккумулятора 950. При отключении может быть пиковое потребление, а 950 при 2С это как раз почти 2 ампера. Если найдете аккумуляторы с разрядом 3С, то можно ставить 650ма/Ч.

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

В данном случае не уверен, схема не моя сдохшие модули стояли в готовых модемах RUS-55iT. Я мог только выключать их АТ командой и ключиком по питанию. Резервный аккумулятор стоит на все устройство с отслеживанием напряжения и отключением при разряде, не помогло .



1 озабочусь, ничего сложного в этом нет
2 спасибо за экономию времени

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

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

Сообщение отредактировал _3m - Feb 20 2013, 10:30

Знаете поговорку - "сдуру можно и ... сломать" Вот и с модулями так же.
Условия озвучены при которых будет гарантировано >>>Флэш слетать не должна и точка.
Нежелание их соблюдать это подход студента недоучки или радиогубителя.

Начнем с того что предусматриваем, что идиот пользователь может на ходу питание дернуть.
От этого нужно защиту делать, а не кричать >>>Нефиг перекладывать свои проблемы на пользователя!
Это как раз проблема разработчика предусмотреть идиота пользователя и обеспечить надежную работу прибора.

Банальный пример - модуль в процессе работы просто обязан обновлять данные в памяти.
Берем ваше "Флэш слетать не должна и точка. Обеспечивайте как хотите"

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

Поэтому
>>>Вот у меня устройство с сетевым питанием, аккумулятора нет и не будет потому что он устройству не требуется, оно не работает без 220. Однако даже 220 модет отключиться и что я должен делать ?

Я могу предложить два варианта:

1. Разумный - предусмотреть это и потратиться меньшей суммой на ликвидацию этой ситуации.

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

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


Этот вопрос обязаны решить разработчики модема. Как - их проблемы, они за это деньги получают и только они знают в какие моменты, и для чего данные пишутся в память. Стоит модем в режиме ожидания, никакие команды на него с моей стороны не подаются. Вырубаем питание (чубайс, однако!) - ничего не должно слететь. Никогда. Со 100% гарантией.



Озвучьте параметры защиты или пункт в ДШ.

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

До поры до времени - повторю ответ из соседней темы.

Запись во флеш идет не при отключении, а в процессе работы. А вы можете просто попасть на этот момент.

Рассказываю что наиболее вероятно происходит.
При записи блока идет циклическая смена адресов автоматом во флеши. При отключении питания оно снижается плавно и может быть ситуация когда адреса уже не валидны, а автомат еще работает. И портится любая область включая бутовую. И защита страниц тут может просто не сработать.

Поэтому ваш ресет от супервизора при работе автомата блочной записи флеши никак на ней не отразится - автомат должен доработать.
И его не сбросить корректно. Так что шанс на то что пропадание питания попадет на этот процесс у вас остается.

>>>Этот вопрос обязаны решить разработчики модема.

У вас широкий выбор производителей - от китайцев до именитых. Расскажите им это. Но думаю что все сразу не могут быть глупыми.

>>>Озвучьте параметры защиты или пункт в ДШ.

Дык уже озвучены выше - все банально. Нежелание это понимать, только ваша проблема.

Plase never power down module using power switch before using the SMSO command, also please avoid having unstable VBATT during power up. Unstable VBATT may cause power loses during initial procedure and cause problems with internal memory. Also while switching off module always wait for the URC SHUTDOWN before unplugging power. Module needs some time to write NV setting before switching off, and if module is powered down during that procedure it may cause flash problems.

Я оставляю Вас с вашим упорством. Видите ли, здравый смысл не нужно прописывать в даташите.

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

практический каждый грамотный разработчик, имеющий дело с флэш, обеспечивает алгоритмы защиты информации на этой самой флэши. их на самом деле не так уж много и все известны.
Вы же предлагаете алгоритмическое решение стоящее месяц времени программиста + тестирование, раскиданное на миллионные тиражи, заменить на аппаратное решение на стороне пользователя. +3$ на каждый модуль.
но это не полное решение проблемы, потому что:
1. затраты ны самом деле больше, для мелкой серии будет уже 6-8$ что уже сопоставимо со стоимостью модуля.
2. аккумулятор имеет ограниченный ресурс - 2-3 года.
3. при минусовых температурах литий не работает, а это уже другие цены или масса и габариты
4. а как быть если аккумулятор сел? юзер провод оторвал? вариантов внезапного пропадания питания масса.
5. а еще литий самолетом отправлять нельзя...

есть другой решение - производителю прямо написать, что модуль работает ТОЛЬКО с аккумулятором, но тогда теряется немалая доля рынка, причем именно крупных потребителей, которые заморачиваются на сертификацию и т.д., оно производителю надо?