Должен ли джел... заказчик учить разработчика держать письку?

По логике "устройства повышенной надёжности" оно зависать просто НЕ ДОЛЖНО никогда, сброс по питанию должен быть по определению, только само питание тоже не должно исчезать. Сторожевой таймер это всё же некая хитрость разработчика, чтобы заказчик не сразу уловил наличие глюков. Зависание означает либо ошибки программы, либо влияние некоторых помех в системе, от которых и надо избавляться....И только потом включать сторожа для самого непредсказуемого случая, который не проявится в испытаниях...А если во время приёмо-сдаточных испытаний уже виснет, то это пока игрушка...Ну и кто платит, тот и заказывает...)))

Коррективы, в первую очередь, надо вносить в бумагу! Договаривайтесь, исправляйте ТЗ, пусть ваши манагеры вместе с вами этим занимаются, а не в гамесы режутся. Не будет бумаги - хрен потом что докажете. Договора на создание научно-технической продукции (а ваш случай почти наверняка этот) делаются на риск заказчика, а не на риск исполнителя! Ничем сверх того, что написано в ТЗ, исполнитель перед вами не отвечает. Бумагу приводите в порядок, еще раз повторюсь.

Ну так и предъявляйте рекламацию на некачественно выполненную работу, если уверены.
Если Вы достаточно квалифицированы, чтобы понять недостатки программного кода - Ваша позиция сильнее, только весь сыр-бор всё равно сосредоточится вокруг ТЗ. Насколько точно и грамотно оно сформулировано.

Crot2: По логике
Это по логике, а в жизни :" Все что может зависнуть-зависает, все что не может , зависает тоже!"
как говорил Жеглов, что-то, типа" дело не в количестве воров в стране, а в умении органов их обезвреживать"
Но потому как наливаются кровью глаза "разработчика" ,когда речь заходит про WDT и BOD , возникает мысль, что нам собираются впарить процессоры , у койх (партии) с этим проблемы.

петр1: Ну так и предъявляйте рекламацию на некачественно выполненную работу, если уверены.
Уверен я только в одном, что в МК не используются выше означенные режимы, и как вывод если он зависнет , то так и останеtся, пока не разрядит аккумулятор. Зависнет-это не сгорит, дыма нет, угольки не предъявишь.

То есть у Вас есть программа?
Уже неплохо. Можно доказать, что код ненадёжен ввиду того-то и того-то.
А если это только из разговоров... Ну у нас тоже то телефону отвечают всякое...

Alexey:
Этот спец не знает даже зачем БОД , я говорю, что бы проц не стер свою флешь. Он - " Такие команды в программе не используются!"

Вы пытаетесь/разговариваете на уровне разработчиков/программистов, а документация должна быть на уровне пользователя и не обязательно "шибко" подготовленного.

Вообще-то сбоить и циклить может даже на 200% отлаженная программа. Есть такие "сбои неизвестного происхождения". По сложившемуся мнению, они случаются из-за очень редких и совершенно случайных "ударов" единичных ядерных частиц космического происхождения (т.е. очень быстрых) по ячейкам памяти. Поэтому наличие включённого сторожевого таймера - это не предмет дискуссии, а обязательный пункт в техзадании.
То же самое можно сказать и о каких-то минимальных органах управления - хотя бы о кнопке сброса.

Спец:
По сложившемуся мнению, они случаются из-за очень редких и совершенно случайных "ударов" единичных ядерных частиц космического происхождения

Да, сколько же можно читать бред?
На все приборы/устройства должны быть определённыё инструкции и никто не должен зависеть от всевышнего. Смешно и грустно одновременно.
Мы живём на планете Земля и должны делать все разработки с учетом земного применения.

Работы надо грамотно ставить. Поэтапность предусматривать. Макет - опытный образец - установочная партия - серийный продукт. Корректировки и доработки по результатам испытаний.
От ошибок и недоработок никто не застрахован. Если нахрапом делать за один этап, да еще и если "деньги вперед", заказчик всегда будет "в дураках".