Как "подвесить" МК?

[Aviacode]

Здравствуйте! Хочу проверить программный вачдог. Помогите советом, как можно гарантированно заставить зависнуть микроконтроллер, который использует внутреннюю синхронизацию (Attiny без кварца, или например esp)? Способ с уменьшением питания не подходит. Создавать помеху тоже не очень. Есть ли еще способы?

[Anydy]

Создать блок пользователя, в нем в loop

Код: Выделить всё

while (1) // или while (true)
{
  // Этот цикл будет выполняться бесконечно 
}

https://ravesli.com/urok-67-tsikl-while/
Всё ...МК ушел в бесконечный цикл
А вообще то программная собачка нифига не работает.....только железная!

[KulibinOrsk]

Подвесить МК - программно.
Перегрузить аппаратно через внешний таймер на любой микрухе. К примеру 555 или по внешнему сигналу.

[Labu559]

Хочу проверить программный вачдог. Помогите советом, как можно гарантированно заставить зависнуть микроконтроллер,

Посмотрите пж. здесь к примеру для внешней реализации WDTimer-а. Посмею полагать, что чисто программного ватчдога не существует в природе из-за того, что программа, которая прекратила свое выполнение, не может контролировать своё выполнение, так как она прекратила своё выполнение в однопоточной системе А если серьёзно, то или: программа циклически генерирует импульсы для аппаратного устройства как-то supervisor или таймер NE555, и каждый приход этого импульса отодвигает на время физическое дёрганье ножки МК- RESET, или наоборот используется аппаратный таймер МК WDT, механизм взаимодействия предоставляется загрузчиком (bootloader) с программной перезагрузкой AVR ассеблерной инструкцией "JMP 0" или тоже "ноги" при переполнении (прерывание!). Читал, но к сожалению не проверял, что заставить МК войти в бесконечный цикл можно некорректной арифметической операцией как-то деление числа на ноль (при условии, что этот ноль не константа и т.о. не может определиться на этапе компиляции). Но врядли такой случай, или описаный выше способ с помощью нескончаемого цикла While и goto, или ожидание МК в популярном интерфейсе I2C подтверждения от приемника АСК-а (при потере связи, не реализованы в Ардуино ядре функции повторного старта или досрочного стопа спецификации интерфейса и часто совсем незаслуженно ругают из-за этого I2С) стоит называть зависанием, так как программа фактически выполняется, системные аппаратные таймеры продолжают "тикать", прерывания работают. Эти случаи описаны как Infinite loop или ErrorsLoop. А сторожевой таймер в МК AVR представляет собой независимый аппаратный асинхронный блок, тактирующийся от отдельного внутреннего RC генератора! Другое дело, когда происходит переполнение стэка, переполнение RAM и даже переполнение массива в функции. В С/С++ обязанность контроля колличества элементов масива возложена полностью на программиста, в функцию передаётся адрес и можно испортить данные по соседнему адресу. Или потеря/некорректность записи/хранения/адресации данных из-за сбоя по питанию(см. RAM Data Retention Voltage и/или Brown-out Detector, что не имеет отношения к аппаратному модулю WDT). Т.е.выполнение программы просто становится невозможным- это точно висит . IMHO, если ошибаюсь - намекните п.ж.- старался объяснить очень распространённые заблуждения попроще:yes:
Уточните для сообщества способ аппаратного всё-таки WDT, который Вы применяете и систему AVR/ESP/ESP32.

[ivansidor012]

[ref]Labu559[/ref],
да нет же

Отправлено спустя 4 минуты 11 секунд:
<<<stack<<<

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1392, room 16
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld

[ivansidor012]

после этого есп сама уходит в ребут всегда!!!

выше это пример.

[ivansidor012]

понятно что нельзя зависать в циклах надолго.

То есть нужно проверить то, что нужно и вывалиться из loop.

Иначе будет отваливаться WiFi, а если дольше (чем сколько в мсек?) не выходить из loop - будет рестарт по вотчдогу.

[ivansidor012]

ключевое: рестарт по вачдогу. Она сама выйдет из цикла с ребутом!!!

[ivansidor012]

достаточно в последней плате подсчитать время всех плат выше

[ivansidor012]

и отправить ее (последнюю плату в луп) до момента получения флагов со всех выполненных выше плат.

т.е. while на самой нижней пока не нижняя не получит все флаги с верхних плат

вот и это и работает. это и есть вачдог на есп.

[Labu559]

[ref]ivansidor012[/ref],
Спасибо, что делитесь своим опытом, но я как-то не увидел противоречий в моих словах и Ваших. Извините, не программист и тем более не ассеблерщик и прошу простить и указать мои заблуждения. Но я же привёл ссылки на материалы, которые использовал. Потому и пишу,
1) что бесконечный (не путать с основным циклом Loop()) цикл- Infinite loop (конечно же если он не находится в обработчике высокоприоритетного прерывания) не может помешать аппаратному штатному WatchDog AVR, который выполняется в прерывании (основного цикла) от переполнения WatchDogTimer-а, как самостоятельного асинхронного модуля который запишет флаг и лог срабатывания сторожевой собаки, в зависимости от настроек "дергнет" ногой RST или ставит курсор в начало адресного пространства (0 адрес условно), где находится загрузчик. Ведь сброс WDтаймера тоже происходит от программного импульса, до генерации которого не дошла очередь за заданное время из-за "Infinite loop"т.е.расстягивания времени основного цикла. Вы это подтвердили

ключевое: рестарт по вачдогу. Она сама выйдет из цикла с ребутом

И такой метод работает с внешним таймером NE555 или супрессором, извините супервизором (очепятка) , который не получит вовремя импульс из програмного генератора (не на прерываниях) или длительного delay() для подзарядки времязадающего конденсатора и тупо закоротит ногу МК RST.
2) Я спросил об

систему AVR/ESP/ESP32

потому что это разные камни, задачи и методы. Espressif скрывает исходники ESP (SDK), потому о ихней собаке можно только догадываться на основании обобщения наблюдений поведения чипа, в отличии от АВР для которых есть AN_2551. Для поддержания сетевого соединения вероятно необходим периодический пинг. И он находится (очевидно ) в прерывании высшего приоритета NMI. Ссылки даю. Прошу обратить внимание на то как модуль Wi-Fi вызывает ребут ESP8266 здесь, цитирую ув.автора "...и когда отключить WiFi, то этого косяка нет..." и здесь: "WiFi и TCP/IP функции библиотек SDK имеют возможность обработать все события в очереди после завершения каждого цикла вашей функции void loop() или во время выполнения delay()...".
3) Понижение питания АВР ниже порога сохранения данных в оперативке обрабатывает аппаратный модуль детектора коричневого выхода (Brown-out, дословный перевод). И работает он чуть по другому- делает и удерживает ресет пока напряжение питания не прийдёт в норму.
4) Лог, (отладочная информация) который выдает загрузчик ESP при старте, подозреваю не конкретизирует посредством какого первичного события (модуля Wi-Fi или Brown-out Detector, и т.п.) был ресет, возможно первые вызывают срабатывание собаки или есть её частью, не знаю. Опубликованый лог есть последствием, а не причиной перезагрузки, с её указанием: аппаратный WDT (cause:4). Для ESP в бесконечный цикл нужно наверное нужно вставлять delay(), чтобы отсечь перезагрузку Wi-Fi модулем. См. пункт ниже.
5) Здесь Ваш лог и обсуждение на русском.
6) Во всех уроках по прерываниям пишут, что нельзя пихать в обработчик прерывания функции, а только флаг, который выполнится в основном цикле и сбросится по выполнении, особенно если в обработчике прерываний запрещаются другие событийные прерывания.

Labu559,
да нет же

Теперь, надеюсь, уже не на столько категорически нет? Спасибо, приятно с Вами вести диалог!
Исправил опечатку, добавил документ.

[Anydy]

[ref]Labu559[/ref], Все верно, но думаю все же надежнее аппаратное решение (я не проверял) .....в основном цикле МК шлет таймеру команду сброса ....как таймер не получил команду --- он нажимает на ресет МК ....все остальное думаю будет глючить...

[Aviacode]

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

Отправлено спустя 47 минут 15 секунд:
Опробовал на Нано, зависает, стандартной защитой Flprog выводит в рабочий режим. Мучают сомнения, действительно ли МК "мертво" висит. Вариант с делением на ноль не сработал, разделил, -1 получается.

[Anydy]

Мучают сомнения, действительно ли МК "мертво" висит.

Так обычным блинком - для Uno, Nano

Код: Выделить всё

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  while (1) // или while (true)
{
  // Этот цикл будет выполняться бесконечно 
}
digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
  
}

При включении МК должен 4 раза мигнуть светодиодом.....далее в зависон и далее код не должен выполняться
нажимаем ресет и то же самое

[Labu559]

Labu559, Все верно, но думаю все же надежнее аппаратное решение (я не проверял)

[ref=#aa0000]Anydy[/ref], ув.Андрей, полностью согласен, потому, что ... тоже не проверял , и прикупил давненько несколько разных супервизоров в т.ч. с енергонезависимой памятью для логирования событий и контролем питания.

Мучают сомнения, действительно ли МК "мертво" висит.

Попробую наверное усугубить Ваши сомнения: нет не "мёртво" и даже скорее не висит?, а выполняет в штатном порядке программу в бесконечном цикле и при этом даже не выходя из... слушает кнопку и отрабатывает её нажатия правда в прерывании. Ничего фатального! Немножко (в Си) изменил и дополнил скетч ув. Андрея выше, что-бы можно было [spoiler title= "лицезреть мои агрументы" из выше] Всё то же, за исключением того, что в бесконечном цикле при отпускании кнопки (нажали- отпустили) в прерывании инвертируется состояние светодиода на 13 пине, и этот фрагмент программы продолжается по выходе из обработчика так и не допустив к остальному коду ниже while.

Cirquite_InfiniteLoop_Interrupt.png

InfiniteLoop_Interrupt.rar

[/spoiler] Думаю тут более вопрос понятий что считать зависанием: аппаратный сбой, всё что мешает выполнению основного цикла за некоторое критическое время, случаи, когда устройство перестаёт отвечать на внешние запросы, при этом таки выполняя програмный фрагмент... Искал определение, нашёл разного: ошибки (Faults), ловушки (Traps), сбои (Aborts), защёлки (Latchs), особые ситуации (Exceptions). Почитал немного даташиты/апноуты про WatchDog и аппаратный TWI (I2С), переполнения функций времени (millis, micros) и т.д.- это примеры недореализации в Ардуино. Поробовал пойти дальше и реализовать в предыдущем скетче переполнение стека, что цитирую: "...в С++ приводит к неустранимому сбою программы".[spoiler title= Stack overflow] Симуляция в Протеус повторяет всё то-же, что и с InfiniteLoop, т.е. замирает, до коротких миганий не доходит, "намертво не зависает", прерывание от кнопки отрабатывает. Информацию черпал отсюда, возможно чего-то "недочерпал". Надеюсь причина- симулятор, вживую на железе пока проверить нет возможности.

OverflowStack_Interrupt.rar

[/spoiler]