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

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

В нашем случае ограничение срока службы? Дык маловато 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 может отключиться и что я должен делать ?

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

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

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

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

Поэтому
>>>Вот у меня устройство с сетевым питанием, аккумулятора нет и не будет потому что он устройству не требуется, оно не работает без 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. а еще литий самолетом отправлять нельзя...

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

Надо объединять темы.

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

Поймите - беда не в модуле. Сама запись во флешку не дает на сегодня 100% гарантии.

Повторюсь еще раз.

Погуглите - этим не только модули страдают. Навскидку в этом же форуме

http://electronix.ru/forum/lofiversion/index.php/t81457.html

Есть куча методов снижения вероятности повреждения данных во флеш, но на сегодня 100% защиты - НЕТ.
Всегда может случиться ситуация при которой бумс и все.....
Даже Хитачи запатентовавшая FlashPowerGuarg говорит о снижении вероятности до 0.5-0.7% но не дает 100% гарантии.

Так что если нужно 100% гарантии работы устройства, то без внешних телодвижений не обойтись. Все равно прийдется обеспечить такой режим работы когда вероятная запись завершится корректно.

Если шанс слетания в пару процентов вас устраивает, то тогда признаю свою неправоту.
Но в свое время мы поимели из-за такого горку GR-47 со слетевшими прошивками, да и где то год назад рассказывали что и вейвкомы слетами тоже страдали при определенных условиях.

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

Я извиняюсь за глупый вопрос, а что за тип флеша используется, что в него так часто пишут? Ресурс памяти не вырабатывается за год?
Может быть, эта ошибка у топикстартера именно по причине запиленности памяти возникла? И в заводских условиях модуль будет не просто перепрошит, а еще как-то отремонтирован? (но об этом никому не скажут)

Могу точно сказать как в SIM900 сделано. Под системную область зарезервирован восьмикратный размер таблицы. И она каждый раз переписывается в новое место. Кстати потому и сложности со сменой ИМЕИ на лету - нужно не только высчитать 15 цифру, посчитать КС блока записи, но и знать куда его переписать в данный момент. Все в принципе решаемо но по сравнению с SIM300D сложнее.
Симком гарантирует что при штатной работе за 10 лет ресурс не выберут.
Когда конкретно пишется - точно не скажу, Но когда я возился с ИМЕИ, читая память модуля, то за день 3 или 4 раза таблица меняла свое место.

Не часто, но тут как в анекдоте:
У мужчины шанс встретить динозавра на улице один к миллиону, а у женщины 50 на 50 - или встретит или нет.

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

Ага, беда в головах. Есть волшебное средство: лес и бита.
После примененя оных к головам разработчеГов волшебным образом программные автоматы обучаются корректному завершению, в схемы добавляются супервизоры, ключи питания, и потребность непрерывно писать что-то во флэш улетчивается. Китайцам следует отыскать в поднебесной аналоги означенных инструментов и применить их к горе-разработчикам модулей.
Потому что то что вы озвучили никуда не годится!


Мне фиолетово кто чем стадает. Я покупаю продукт и внутреннюю кухню продукта знать не желаю! Плачу деньги и хочу просто пользоваться изделием а вместо этого мне предлагают решать проблемы которые не осилили производители модема.

no comment

Но за хорошее настроение спасибо.

Вот объясните мне на кой надо постоянно переписывать IMEI в разные места флеша. Это константа и менять по хорошему ее нужно 1 раз на заводе, ну еще пользователю разик. И много чего другого можно не трогать а в области настроечных констант держать. А то что останется наверняка можно потерять. Единственная причина постоянной записи во флеш это своп озу, дык и при этом рестарт операционки и все дела.

В общем тему надо закрывать она уже не соответствует названию.

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

Изумительно! А счетчик перезаписей есть ? чтобы когда он переполнится модуль склеил ласты ?
У меня индустриальное примение. 10 лет в индастриал - семечки. Допустим расчитали ресурс на 10 лет, он закончился -> флэш помирает. Какие симптомы ? Какие коды ошибок ?? Что-то я в документе по AT командам не припомню сообщеий об исчерпании ресурса модуля.

У меня в контроллере кстати реализована похожая схема работы с флэшем. Не самое эффективное решение, но довольно простое.

Ну это действительно странно, основной флеш, по логике и сделан, чтоб постоянно хранить фирмваре и все!! Допускается его перепрошивка, но это в очень редких случаях, больше перезаписи быть не должно.
Чувствую - программеры "зажирели" с тех времен, когда использовались масочные или УФ-ПЗУ...

Для хранения переменных среды и др. настроек всегда использовался EEPROM- отдельная область памяти, которая есть почти в каждом МК. Причем к фирмвари она не имеет никакого отношения, и даже, если она будет повреждена при пропадании питания в момент записи, то при след. рестарте программа определит это и заполнит дефолтными значениями. При этом работоспособность устройства будет сохранена! Почему в модемах не так - трудный вопрос...

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

EEPROM имеется далеко не во всех МК, для ARM-ов - наличие eeprom скорее редкий случай. А на АВРах и ПИКах модемов почему-то не делают.

Решение хранить данные во флеш - это нормально. Главное правильно это реализовать, чтоб хватило ресурса флеш минимум на 10 лет и не происходило сбоев фирмваре. Ставить дополнительный eeprom это затраты денег, площади платы. При тираже миллион экземпляров, экономия всего в 0,5 доллара дает 500000$

Ну эт может быть, хотя и зря. Не всегда нужно хранить мегабайты конфигурации...

А вот что странно, дак это пресловутая "паразитка", о которой тут пол-форума пишет. А странно то, почему она так влияет, скажем, есть ток по линиям данных, допустим пол-милиампера, при напряжении 3в. Ток потреления модема при запуске - где-то 20-30 ма, следовательно, на его контроллере, напряжение не поднимется выше 0.5в. Но даже если и поднимется до 1 или 2В, что это даст? Конечно, если в таких навороченных армах нет и схемы сброса с детектором напряжения - то это вообще алез!! А если есть, то никакое ядро запуститься там не может, т.к. будет находиться под активным ресетом. В чем тогда проблема??

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


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

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


Опять же во вменяемых soc предусмотрены супервизоры для всех питающих напряжений. Если VDDIO не в норме (а при паразитке оно явно не в норме) RESET удерживается активным.
Но это не китайский случай.
Применение биты крайне необходимо, причем неоднократное!

А кто сказал что при старте?

Если Вы не в курсе, разработкой ядра занимаются не китайцы. До недавних пор это было вообще "маде ин USA".

А кроме того... При удерживании RESET потребление стремится к нескольким мкА, что приводит к тому, что питание(VDDIO) обеспеченное паразитными цепями стремится к напряжению приложенному к этим цепям. Т.е. если на ногах осталось 3В, то и на VDDIO будет те-же 3В.

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



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

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


Он самый слип и есть. Все запитано, но стоит и не работает...

ЗЫ. Кстати, ток потребления ядра GSM-модулей мал - основной потребитель там приемник. Это заметно по тому как резко падает потребление при включении поллинга приемного канала(DRX).

Согласен с коллегами в том, что последнее дело, когда производитель ставит потребителя в ситуацию: не дышать, подходить только в тапочках с помытыми руками и т.д, а иначе игрушка сломается. И дело не в том, то это принципиально не решаема проблема, а в примитивном подходе и мышлении программистов (не знаю уж чьих). Как говорится: "дело не в бобине, а в прокладке между сидением и рулем".
Зачем идти на лобовой алгоритм записи массива во флеш, требующий, иногда, достаточно много времени? Почему нельзя обновлять/переносить, т.е. производить операции с флешем "порциями" - в пределах временных возможностей, к примеру, конденсаторов фильтра удерживать достаточное напряжение для работы контроллера?
Я давно использую этот алгоритм работы с флешами. Достаточно контролировать пропадание питания, и правильно выбрать размер "порции" (кол.записываемых байт). Размер "порции" зависит от возможностей "аварийных источников" (конденсаторов фильтра, ионисторы и т.д). Как только пропадает питание - по прерыванию поднимается флаг. МК "дорабатывает порцию" (ему для этого всегда гарантировано хватит времени), проверяет флаг и... тихо "умирает" в безусловном цикле ожидания. А вести учет: что обновлено, а что нет - дело техники.

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

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

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

Иными словами - такого модуля нет, который не занимается самопроизвольной записью во флеш?

Видимо нет. В теме
http://electronix.ru/forum/index.php?showtopic=110530
ищем модули где запись во флеш не приводит к отказу