Использую процессоры от Silabs: 581, 344, 411, а ранее были 311 и 064.
Так что опыт есть.

Нареканий на процессоры, компилятор keil (успешно мигрирую на поздние версии) нет,
за исключением регулярного слетания отладчика с громким падением Keil'а.
Эта проблемка лезет из dll'ки отладчика EC-3. Пристальное вглядывание в землю отладчика
выявило короткие и редкие всплески при двигании мышкой, подключенной тоже по USB.
Но с этим как-то привык уже жить.


Неделю назад столкнулся с другой проблемой на 344 процессоре и до сих пор её решаю:
При интенсивной записи (10 раз в секунду) в страницу встроенного FLASH процессор ресетится,
в регистре источника ресета (RSTSRC) торчит бит-3 - источником ресета был watch-dog.
Такая частая запись флэша в работе устройства применяться не будет, просто шла отладка драйвера
на ПК и тут вылезла описанная выше проблема в устройстве.

Вотч-дог взведён на 3 мс - максимально возможное время для используемой конфигурации процессора.


1. Отключил вотч-дог - проблема пропала.
2. Вернул вотч-дог и наставил его доп. сбросов - не помогло.
3. Проанализировал код на наличие опасных мест связанных с запрещением прерываний. Ничего не нашёл.
4. Отключил запись во FLASH, оставив только запись во внешний EEPROM - проблема не проявляется.
5. Сделать эмуляцию ватч-дога для отлавливания места и состояния когда происходит истечение таймаута вотч-дога:
отключил настоящий ватч-дог и вместо него задействовал свободный таймер,
сконфигурировал его на аналогичный ватч-догу интервал,
а на его прерывание по переполнению поставил точку останова.
Запустил тестовую утилитку на ПК и ... ничего не произошло, всё работает, прерывание по переполнению таймера не возникает в течении 4 минут.
Уменьшал время таймера-эмулятора ватч-дога, до тех пор пока прерывание не начало появляться. Это начало происходить при времени < 0.2 мс.
Т.е. таймаута штатного вотч-дога гарантированно хватает.

Получив этот результат, мысли "куда копать" иссякли.

Забавно..
У меня подобным образом FLASH пишется на F022 и F314, сбоев не замечал.
Это под отладчиком проявляется или всегда?

Время цикла стирания 15мс + цикл записи 55мкс: может просто маловато 3х-милисекундного сторожа?

Игорь, спасибо за ответ!

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

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

Время стирания флэш на 344 эти же 15 мс, прерывания на время стирания и сам вотч-дог запрещены, согласно рекомендациям SiLabs.
Отличия, конечно, от последовательности записи/стирания от апнотовских имеются: раздельная запись ключей, первая часть ключа
пишется в специально выделенном для этих целей прерывании, разрешение которого делается отдельной функцией, вторая часть ключа
пишется в самих функциях, но с обязательными проверками залочивания флэш и проверкой что первая часть ключа записалась.
Сделано так для избежания самопроизвольного стирания флэш при различных внешних условиях.

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

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

Может быть, как-нибудь проверю и эту идею.
С другой стороны VDD-монитор включен, источником ресета он никогда не был.

Сделано...
В процессе добавил отслеживание ещё одной ноги, которая на том же PCA0 генерирует частоту наружу.
Диаграмма такая:
Нажмите для просмотра прикрепленного файла

Нулевой канал логического анализатора показывает ресеты,
первый канал - тоглы пина при сбросе ватч-дога,
третий канал - генерируемая процессором частота (~1,2 МГц).

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

Источником ресета (по значению RSTSRC) снова является ватч-дог...