Перейти к содержанию
    

Новые STM32H7 - два ядра (M7+M4), 480 МГц

1 час назад, haker_fox сказал:

Который, скажем из-за выхода из строя какой-то периферии, стал циклически перезагружаться вотчдогом.

У МК есть статусный регистр с указанием источника перезагрузки.

Если у вас 10 перезагрузок от IWDT, то это можно программно определить. Есть флаги перезагрузки по пину RESET и подаче питания POR.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 часа назад, haker_fox сказал:

Я имел в виду не отладку на столе, а прибор. Который, скажем из-за выхода из строя какой-то периферии, стал циклически перезагружаться вотчдогом. Т.е. запускается, делает какие-то действия, перезагружается, снова выполяет действия и т.д. Т.е. цикл "старт устройства, перезагрузка" и так до бесконечности может быть нежелателен. Ведь до перезагрузки прибор может начать выполнять какие-то действия, например, закрывать задвижку на газопроводе.

Так если работа программы возможна без этой периферии, то пишите её драйвер так, чтобы программа не висла. Ведь WDT срабатывает при зависании ПО, а не периферии.

 

PS: Мне в одном из устройств по ТЗ необходима была замена LCD на "горячую". При том что LCD был подключен по I2C и всё время обновлялся. И ничего - реализовал. И даже можно менять на LCD другого типа (сегментного на графический и наоборот) на ходу и без перезагрузки. И ничего не виснет.

В другом девайсе вис кодек, подключенный по I2C и I2S. Вис изредка, из-за воздействия помех. Схемотехнически побороть не удалось. Тоже сделал периодический опрос состояния и сброс через ключ на питание.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, haker_fox said:

... а прибор. Который, скажем из-за выхода из строя какой-то периферии, стал циклически перезагружаться вотчдогом.

IMHO, так не должно быть. Никакой выход из строя периферии не должен приводить к таким последствиям.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, haker_fox сказал:

Написать программу "маэйнлупом", без прерываний по поллингу, и, я думаю, будет работать...

Гы:smile:

У меня самописный кооперативный планировщик, который я однажды уже представлял на обзор любым заинтересованным:bb: Глюков замечено не было...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 hours ago, aaarrr said:

Сохраняйте состояние в RAM, принимайте решение по восстановлению после сброса.

Да, точно! А ведь простое решение я сразу и не увидел. Спасибо!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, Aleksandr Baranov said:

IMHO, так не должно быть. Никакой выход из строя периферии не должен приводить к таким последствиям.

Ну "не должен" это в теории. На практике я наблюдал совершенно иные результаты. Конечно они были из-за некачественно написанного ПО. Но всё же. Суть-то вопроса не в этом.

1 hour ago, Arlleex said:

Глюков замечено не было...

Тем более! Тогда вместо какой-нить pca9543 самое милое дело поставить маленький cortex-m0.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 часа назад, jcxz сказал:

PS: Мне в одном из устройств по ТЗ необходима была замена LCD на "горячую"...

Просто интереса ради - а чего за девайс такой, что вандально дисплей приходилось отдирать?:blush:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

29 минут назад, Arlleex сказал:

Просто интереса ради - а чего за девайс такой, что вандально дисплей приходилось отдирать?:blush:

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

Нет. Счётчик электроэнергии.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 часов назад, haker_fox сказал:

Написать программу "маэйнлупом", без прерываний по поллингу, и, я думаю, будет работать. Единственное, нужно тщательно тестировать. Но и, на всякий случай, завести ножки программирования этого простого МК к "большому брату". чтобы иметь возможность перепрограммировать его.

Никогда не делал никаких удаленных обновлений и не буду, ибо стараюсь разделить задачи для МК, которые не надо будет никогда обновлять (тривиальные операции, расширители портов и стандартные интерфейсы) и основной МК, который грузится с СД карты и прошивка и вспомогательные файлы - все на карте. Обновить ПО простым копированием на любом компе, и бэкап сделать можно аналогично...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, haker_fox сказал:

Да, точно! А ведь простое решение я сразу и не увидел. Спасибо!

А можете описать это решение? По-моему, ОЗУ никак не поможет определить был это сброс по питанию, внешнему сигналу RESET или watchdog`у.

Чем биты регистра RCC->CSR не угодили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 hours ago, adnega said:

А можете описать это решение?

В устройствах, которыми я занимаюсь, есть часы реального времени и немного байт ОЗУ, которое питается от батарейки. Мы можем в регистрах МК узнать причину сброса и записать эту причину с отметкой времени. Если с момента времени предыдущей загрузки прошло менее, чем N сек, то можно заблокировать себя в вечном чикле. Или поступить более сурово: запустить схему crowbar, которая пережгёт предохранитель и обесточит нас гарантированно. Алгоритм можно усложнить, и анализировать, к примеру, не только время от предыдущей загрузки но и то, была ли она успешной, сколько раз мы уже перезагрузились на отрезке времени K сек и т.д. и т.п. Тут, естественно, есть нюансы. Если это часы на шине I2C, то нужно на момент загрузки иметь рабочий драйвер. Если это МК типа LPC4337, то пара сотен байт у нус висит прямо на внутренней шине, и сразу готова к использованию. В принципе, если это только перезагрузка, то мы можем использовать обычную ОЗУ внутри МК. Её значение не измениться, если это будет секция __no_init.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, haker_fox сказал:

Или поступить более сурово: запустить схему crowbar, которая пережгёт предохранитель и обесточит нас гарантированно. Алгоритм можно усложнить, и анализировать, к...

Да, действительно сурово...  Неужели проблема с этими перезагрузками так актуальна и требуется такое "оперативное вмешательство"??

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, mantech said:

Да, действительно сурово...  Неужели проблема с этими перезагрузками так актуальна и требуется такое "оперативное вмешательство"??

Нет, я это уже в качестве примера привёл)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 minutes ago, Михась said:

Сейчас понял что этим двуядерникам нехватает - еще одного ядра М0!

Всегда говорил, и буду говорить: не хватает маленькой cpld на этом же кристалле, абсолютно независимой от МК.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...