[Alt.F4 2]

Здравствуйте.

Изучая документацию на новый модем, возникло несколько вопросов:

 

1. When the module is working, cutting off the power of the module will damage the flash.

Как это понимать, а если пользователь снимет питание с устройства, то приехали?..

 

2. When the temperature exceeds the range of - 40 ~ + 85 ℃, A7682E will shut down automatically.

Для чего этого сделано?..

[CADiLO 9]

1. Да, это особенность чипсета.  Но там есть нюанс. Если питание пропадет быстро, то шанс на неправильное срабатывание секвенсора питания мизерный и все будет в норме.

Но если на модуле останется большая емкость по питанию и спад будет плавным, то.... Хотя эта проблема есть и у остальных модулей, но в меньшей степени.

Если план питания продуман, то все будет в норме. А если LDO и конденсатор на пару тысяч микрофарад, то кто ж доктор такому питанию....

 

2. А зачем модулю работать при значениях температуры при которых его нормальная работоспособность не гарантируется. Банальная защита от дурака претензий.

[Alt.F4 2]

12 минут назад, CADiLO сказал:

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

Регламентированы ли временные рамки, за какое время и до какого значения напряжение должно упасть, чтобы модем не вышел из строя?..

Иначе, судя по даташиту, получается, что девайс на свалку, как только мы передернем питание модему внешним ключом (например, если модем перестал отвечать по UART).

 

19 минут назад, CADiLO сказал:

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

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

[jcxz 184]

19 минут назад, Alt.F4 сказал:

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

Или модем тупо зависнет, по причине выхода из допустимого эксплуатационного диапазона температур (а он вполне вправе так сделать).

Так что - то же самое гадание: то ли завис (из-за выхода за диапазон температур), то ли питание выключилось.  

[CADiLO 9]

41 minutes ago, Alt.F4 said:

Регламентированы ли временные рамки, за какое время и до какого значения напряжение должно упасть, чтобы модем не вышел из строя?..

Иначе, судя по даташиту, получается, что девайс на свалку, как только мы передернем питание модему внешним ключом (например, если модем перестал отвечать по UART).

 

Менее 100 mS. Так в даташите на чипсет для SIM800x.  Думаю что для остальных примерно также.

Если посмотрите на пример питания от LDO в даташите на модули, то там не зря разрядный резистор нарисован.

 

[ELSE 0]

@CADiLO

Добрый день. 

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

[CADiLO 9]

Флеш не убивается. Портится часть прошивки (может даже один бит и может даже в свободной зоне) если в этот момент происходила запись в нее.

Вероятность такого мизерна, но из-за того как реализована запись в самой микросхеме памяти, вероятность остается в любом устройстве.

Никакая прошивка это не исправит, это физическая работа автомата записи в микросхеме.

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

[antis 1]

@CADiLO

А в какие моменты происходит запись во флеш?

[CADiLO 9]

Это вопрос даже не к Simcom, а к тем кто писал RTOS для модулей.

 

 

[ELSE 0]

6 часов назад, CADiLO сказал:

Флеш не убивается. Портится часть прошивки (может даже один бит и может даже в свободной зоне) если в этот момент происходила запись в нее.

Вероятность такого мизерна, но из-за того как реализована запись в самой микросхеме памяти, вероятность остается в любом устройстве.

Никакая прошивка это не исправит, это физическая работа автомата записи в микросхеме.

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

Вы это имели ввиду в целом вообще или конкретно про A7682E? Если в общем, то оно не вызывает вопросов. Если же конкретно про "излишнюю чувствительность " a7682e, то меня смутил сам оборот:

cutting off the power of the module will damage the flash.

Что дословно "...приведет ( т.е. безусловно) к повреждению..." данных/flash .

хотя обычно встречал предупреждение что все не записанные данные МОГУТ быть потеряны и т.п., но ни как не категорическое утверждение.

Придется включить в тестирование.

[CADiLO 9]

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

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

Естественно изменяется заряд ячеек буфера который переписывается и данные становятся недостоверными.

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

Вывод Power Good не просто так делают, но иногда и это не спасает.

И чем тут модуль хуже?  Все тоже самое.

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

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

 

[jcxz 184]

15 минут назад, CADiLO сказал:

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

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

Естественно изменяется заряд ячеек буфера который переписывается и данные становятся недостоверными.

Вы думаете - сама схема записи во флешке некорректно построена? Что может сделать недостаточный заряд ячейки при записи?

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

И сколько работаю с микроконтроллерами - не помню чтобы с таким когда-то сталкивался. Если конечно в ПО реализованы необходимые механизмы надёжной записи и нет багов в них.

Вообще - ничего сложного в реализации (в ПО) записи флешь, устойчивой к сбоям не вижу. Разве что в каких-то специфических случаях.

20 минут назад, CADiLO сказал:

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

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

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

Если и строить монитор питания, то естественно не на аккумуляторе, а на большом конденсаторе по высокому питанию. Но и это может не спасти.

Как-то в одном проекте хотели заменить FRAM на чипы от Cypress, где внутри флешка+монитор питания (на внешнем конденсаторе). Типа - эмуляция FRAM. Более дешёвая, нежели FRAM. Вроде как гарантируется, что схема в чипе успеет сбросить все буфера записи по аварии питания. Так - на столе всё работало. Но когда понесли на испытания на ЭМС - начались слёты данных. Что-то там иногда не всегда корректно сбрасывалось. Вернулись к FRAM.

[CADiLO 9]

Ага - щасссссс.... вылизана....

Берем гугль.

Ищем - FLASH Corruption - находим массу документов описывающих как причины так и механизм.

Навскидку - https://community.silabs.com/s/article/flash-corruption?language=en_US

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

Ну и картинка с питанием и внутренним сбросом в чипе - все равно не спасает, хоть и минимизирует ошибки.

 

 

[jcxz 184]

1 час назад, CADiLO сказал:

Ищем - FLASH Corruption - находим массу документов описывающих как причины так и механизм.

Навскидку - https://community.silabs.com/s/article/flash-corruption?language=en_US

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

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

1 час назад, CADiLO сказал:

Ну и картинка с питанием и внутренним сбросом в чипе - все равно не спасает, хоть и минимизирует ошибки.

Если проблема в этом, то спасать должно элементарное отделение питания флешки от питания записывателя в неё (МК). И навешивание на это питание дополнительной ёмкости. Чтобы держало напряжение питание в пристойных границах чуть дольше (на макс.время записи).

[CADiLO 9]

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

Но вопрос о том где уже все сделано внутри модуля.