SiLabs'ы "встроенный вотч-дог" vs "запись Flash" Опции

[richie]

Использую процессоры от 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 мс.
Т.е. таймаута штатного вотч-дога гарантированно хватает.

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

[richie]

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

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

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

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

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