У меня куплена партия кристаллов f930 ревизии с1 и есть немного e3. С точки зрения "подвисания" во время нахождения в sleep разницы не заметил.


Если не секрет, как Вы выполняете переход в sleep? С отключением crossbar-а или нет? Для минимизации потребления в sleep это принципиально. Во всяком случае для меня.

согласно выше приведенному примеру, кроссбар не трогаю...

Всем добрый день. Используемый режим работы:
Спящий режим не более 5 минут, затем работа с различной периферией (в зависимости от текущей задачи), снова сон.
Проблема (зависание МК) возникает через время от 2 до 10...14 дней стабильно для контроллеров начиная с ревизии С, и на сейчас используемой ревизии Е. Эррата прочитана и учтена.
Как нюанс - в процессе работы использую различные тактовые сигналы.
Еще успел заметить, что потребление в "нормальном" спящем режиме отличается от потребления при зависании (15 и 30 мкА соотв.)

Замечание и парочка вопросов по C8051F99x.
Есть такая программа для облегчения конфигурации периферии силабсов, называется Configuration Wizard. Так вот: порождённому ей (версии 2.90, новее вроде пока нет) коду для конфигурации встроенного прецизионного RC-генератора (регистр OSCICN) верить нельзя. В даташите прописано, что младшие 5 бит этого регистра зарезервированы (явно не указано, для чего), а визард выдаёт OSCICN = 0x8F, т.е. устанавливает 4 младших из них. Последствие - тактовая частота вместо положенных 24,5 МГц составит около 26,25 МГц (установлено экспериментально). Потому - эти биты не трогать: OSCICN |= 0x80.

Теперь пара вопросов. Просьба сильно не пинать, если уже было, просто ткнуть носом - поиск здесь не совсем совершенный.
1. По SmaRTClock. Хоть тресни, не выходит на прерывание по ALARM. Если у кого есть рабочий код инициализации, был бы признателен. Свой, если понадобится, выложу, пока не хочу загромождать. Временно забил на RTC, приспособив таймер 2 для генерации секундных интервалов, но оно некрасиво как-то.
2. По CS0. В даташите явных указаний на эту беду нет, есть только упоминание насчёт того, что начальное значение измеренной ёмкости не равно нулю и зависит от паразитной ёмкости монтажа и т.п. (ну логично). Так вот, при минимальном усилении (CS0MD1=0) оно таки равно нулю, а при максимальном (CS0MD1=7) тоже не совсем правдоподобно; расчётное значение, исходя из топологии платы, около 1,5 пФ, а отдаётся почти 7 пФ. Прямой пропорциональности относительно значения CS0MD1 нет, а вроде ж должна быть... опять же, код выдам, если кто заинтересуется.

Скорей всего при настройки внутреннего генератора C8051F99x все делается верно. Вообще процесс записи в зарезервированные биты не должна влиять ни на что. Возможно другая частота получается из-за погрешности внутреннего генератора +-2%.

От 410-го не пойдет? Пробежался поверхностно - вроде модули похожи. Нет - извиняйте (К стилю прошу не придераться, писал давно. И расту, по-тихоньку)

Похожи. Спасибо, попробую и так. В 990-х RTC всегда разлочены, записывать RTC0KEY не нужно (якобы??? я поверил и не записывал). Ну и ещё использовал short strobe вместо поллинга занятости - может, там затык.

Добрый день.

На всякий случай, решил добавить немного от себя (то же по опыту работы с F410).
Для ALARM прерывания необходимо разрешить работу ALARM в RTC, разрешить работу самого RTC и запустить таймер RTC. В MCU разрешить работу прерывания RTC. Обновлять регистры RTC необходимо с вычитыванием старого содержимого, а то можно выключить прерывание. И еще. Для сброса прерывания необходимо обновить значение ALARM на новое, иначе тут же выйдя из прерывания снова в него попадете (ну или вообще отрубить работу ALARM).

Удачи.

Вот это интересно... выходит, что т.н. Autoreset использовать в чистом виде не получится?
(Посмотрю-ка ДШ на 410, может, там подробнее... кхм. Нет там Autoreset...)


А влияет. И не совсем явное указание в даташите на это есть: - относительно битов 5:0 OSCICN.