Чем внешний watchdog лучше встроенного в МК? Опции

[r0pegig]

Интересно мнение других. Сам пока не вижу большого смысла во внешнем, если есть внутренний.
Есть предположение, что по внешнему можно сбрасывать не только процессор, но и другие микросхемы на плате. Хотя опять же это можно делать программно, если ножки сброса подключить к МК.
Какие есть еще соображения?

[vlad_new]

Бывают такие баги в больших чипах которые можно сбросить только отключением питания.

Обсалютно точно. Во первых надо разделить апельсины от софта. Откуда берется зависание?
1. От не запланированного хода выполнения кода программы.
2. От внешних факторов - грязное питание, и, в основном, от статических разрядов.
В первом случае внешняя собака не нужна.
Во втором случае, многие из ARMов не возможно сбросить по резету в 50% зависания. Поэтому если использовать внешнюю собаку, то обязательно нужен механизм дерганья питания.

[_Артём_]

многие из ARMов не возможно сбросить по резету в 50% зависания

Это о каких АРМах речь?
К СМ3, СМ0 тоже относится?

[kan35]

Это о каких АРМах речь?
К СМ3, СМ0 тоже относится?

блок Reset не входит в состав ядра, поэтому такой вопрос не корректен. Лучше пусть скажет конкретные серии микроконтроллеров.
я считаю, что это не правда :-) - может быть какие то специфические экземпляры и страдают такой болезнью, но говорить о 50% никак нельзя так как точно не относится к мэнстримовым чипам популярных брендов.

[vlad_new]

блок Reset не входит в состав ядра, поэтому такой вопрос не корректен. Лучше пусть скажет конкретные серии микроконтроллеров.
я считаю, что это не правда :-) - может быть какие то специфические экземпляры и страдают такой болезнью, но говорить о 50% никак нельзя так как точно не относится к мэнстримовым чипам популярных брендов.

Я имел ввиду в 50% при сбоеях резет не помагает ( лапка не чует ничего ), а не весь парк чипов. Есно к PIC это не относится. Но поскольку мы в теме АРМов, то они и имелись ввиду. Cortex0,3,4. Касается ли это 8,9 ядер - не знаю. Но поскольку механизм ядра разделен от переферии, то думаю, что и там будет то же самое.

[kan35]

Я имел ввиду в 50% при сбоеях резет не помагает ( лапка не чует ничего ), а не весь парк чипов. Есно к PIC это не относится. Но поскольку мы в теме АРМов, то они и имелись ввиду. Cortex0,3,4. Касается ли это 8,9 ядер - не знаю. Но поскольку механизм ядра разделен от переферии, то думаю, что и там будет то же самое.

Есть ли подтверждения ваших умоаключений какими нибудь производителями или если вы грешите на ядро, ARMом? Несколько лет работаю с STM32, ранее работал с ARM7 и разными 8 битниками и чтобы в каких то случаях внешний ресет не работал - не встречалось ни разу и ни от кого не слышал.

[Tahoe]

Есть ли подтверждения ваших умоаключений какими нибудь производителями или если вы грешите на ядро, ARMом? Несколько лет работаю с STM32, ранее работал с ARM7 и разными 8 битниками и чтобы в каких то случаях внешний ресет не работал - не встречалось ни разу и ни от кого не слышал.

У меня есть версия. Это пошло от криворуких программеров, которые не инициализируют грамотно периферию, а полагаются на POR. Соотв., после того, как сработал WD, часть периферии не инициализирована полностью, отсюда и мифы о "недосбросе".

[Forger]

У меня есть версия. Это пошло от криворуких программеров, которые не инициализируют грамотно периферию, а полагаются на POR. Соотв., после того, как сработал WD, часть периферии не инициализирована полностью, отсюда и мифы о "недосбросе".

Во-во! Полностью подтверждаю!
Не раз чехлил своих программеров за подобную лень

Да, но сброс от WDT не должен разве приводить периферию в исходное состояние?

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

[jcxz]

Во-во! Полностью подтверждаю!
Не раз чехлил своих программеров за подобную лень

Бывает периферия (внутренняя), которую невозможно сбросить НИКАК иначе как по внешнему ресету или ресету от внутреннего сторожевика.
Сам сталкивался с таким. Пример: FIFO-буфер DMA-канала в TI CC5502. Если остановить DMA в момент, когда чтение источника произошло, а запись в приёмник - ещё нет (т.е. - FIFO DMA содержит данные), то сбросить этот FIFO нет никакой возможности (в DMA-контроллере нет битов сброса, а enable каналов не влияет на fifo). Сбросить можно только через reset. Если не сбросить FIFO - думаю понятно что будет.
С тех пор как столкнулся с этим, всегда выполняю перезапуск firmware аппаратным сбросом (через WD или соотв. биты если есть).

Хоть и не ARM, но могу в качестве примера привести самый популярный мк с USB 2.0 - CY7C68013A. Если сбрасывать с отключением питания, то работает замечательно, что естественно для USB устройств. Если питание не отключать, то иногда на сброс не реагирует. Спасает только отключение питания.

Работал с CY7C68013A, вроде не замечал проблем. А может у вас не на сброс не реагировал, а по сбросу прошивку с внешней I2C-EEPROM не считывал или криво считывал и соответственно запускал прошивку не с EEPROM, а свою внутреннюю?

Хорошо что это не требуется делать в PIC.
Я обычно сначала эксплуатирую устройство без WDT и если в течении месяца другого не происходит зависаний, можно смело запускать только внутренний WDT.

Вы наверно не пользовались испытательными генераторами импульсных помех
Когда-то помню испытывал устройство (в котором был только внутренний сторожевик) генератором ИГЭ15.2 - подавал пачки эл-статических разрядов. Примерно на каждой 10 пачке устройство висло. Хотя разрешение внутреннего сторожевика было в самом начале main(). Видно второй импульс пачки приходил когда управление находилось ещё внутри bootROM процессора (ещё не проверено состояние бут-пинов и не передано управление рабочему ПО), либо управление было в startup-коде си-программы.

[dinam]

Работал с CY7C68013A, вроде не замечал проблем. А может у вас не на сброс не реагировал, а по сбросу прошивку с внешней I2C-EEPROM не считывал или криво считывал и соответственно запускал прошивку не с EEPROM, а свою внутреннюю?

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

[jcxz]

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

Я уже не помню дергал-ли отдельно сбросом. Помню что была проблема с чтением EEPROM сразу после ресета или включения питания. Но контроллер при этом перезапускался и работал как если бы EEPROM не было.