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

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

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

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



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

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


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

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

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

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

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

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

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

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