Форум РадиоКот

Ломаю голову над принципиальной схемой восстановления дефолтных настроек в микроконтроллере, а в частности STM32F407. С программой буду разбираться позже.
Хочется сделать по принципу большинства роутеров: на одной кнопке и Ресет и восстановление (если долго держать).

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

Рассматривал также супервизоры питания с ручным ресетом (например APX823). Но проблема в том - что выход ресет они держат до тех пор, пока кнопку не отпустишь + задержка. То есть все-равно нужен одновибратор.

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

Спасибо.

Как же в роутерах эта часть реализирована?

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

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

Что значит "повис" ? Почему он от кнопки должен повиснуть ? А программный ресет многие МК имеют. Одна команда - и проц сбросился.
Смотрим, нажата ли долго кнопка. Если нажата - сохраняем параметры по умолчанию и ресетим МК. Не вижу никаких заморочек и проблем...

Аlex писал(а):Что значит "повис" ?

Аlex писал(а): Одна команда - и проц сбросился.

Ввиду каких либо обстоятельств МК перешел не по тому адресу или исполнил не ту инструкцию, поломал конфигурацию портов, его внутренний мир стал набором рандомных комманд, а для внешнего мира он станет доступен только после подачи ресета на соответствующую ногу МК.

Но, есть еще одна идея - использовать супервизор питания с сторожевым псом, повешаным на аппаратный ресет, а вот кнопкой делать программный. Тогда повисший контроллер перезагрузится супервизором, а в случае необходимости - 100% рабочий (программно) МК перегрузится командой.

Если больше идей не будет, остановлюсь на этой.

Для этого есть вач-дог. Он сбросит контроллер если его не дернуть вовремя.

В большинстве случаев контроллер не сможет перейти по произвольному адресу, только если специально не увлекаешься вычисляемым переходом(что в контроллерах не особо распространенная практика)

Alexeyslav писал(а):В большинстве случаев контроллер не сможет перейти по произвольному адресу

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

Спасибо, господа, за консультацию

К меньшинству случаев я отношу программистское раздолбайство, от команды RJMP 0x176 никакой компилятор не спасет... просто не надо в таких случаях константы использовать НИКОГДА, даже если очень хочется!

Я не отношусь к касте тех, кто использует подобные комманды. Даже если очень надо... Есть много других способов. А ошибочое значение регистра может случиться под действием внешних факторов, наводок. Даже пусть это случиться на 3246 или ином другом часу работы устройства. А если есть возможность избежать этого, то почему бы не сделать? Заодно и отказоустойчивость улучшить.

В общем, нашлась схема, удовлетворяющая условия. Если кому интересно:

Но, я все таки решил остановиться на программном ресете с GPIO.

phenomen писал(а): Заодно и отказоустойчивость улучшить.

У вас странные представления об отказоустойчивости...
Кнопка пересброса - крайний случай, аварийная ситуация, по сути... о какой отказоустойчивости тогда идёт речь???

Простите, но как вы бы решили проблему повисшего контроллера? Отключить и включить обратно питание? Или все-таки нажали бы кнопку ресет?
Если есть МК, есть программа, значит есть и вероятность сбоя.
Да, не спорю, слишком придирчиво подошел к проблеме и у меня нет опыта работы с ватчдогом STM32F и потому спросил о проблеме ресета и сброса настроек.
Зато теперь знаю про апаратные средства сбрасывания контроллера + (по схеме выше) апаратный сброс и вывод на GPIO.

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

phenomen писал(а):Простите, но как вы бы решили проблему повисшего контроллера? Отключить и включить обратно питание? Или все-таки нажали бы кнопку ресет?

Я бы отключил питание... секунд на несколько...
Работа МК "по включению" и "по пересбросу" отличается... "Или нет?"(С)
Особенно, если неизвестна причина сбоя, как в вашем случае... Ведь анализировать причину вы и не собираетесь, как я понял...
Ведь вам просто нужна "мэйжик кнопка"... а ля "китайская крутизна"... как решение всех проблем... ничего общего с отказоустойчивостью не имеющая...

Если есть МК, есть программа, значит есть и вероятность сбоя.

Тогда штудируйте посты tester (testerplus) на этом форуме, на Казусе и на Микрочипе...
Начните с железа... более 98% сбоев - по вине железа и неправильной разводки ПП...
Для устранения возможного влияния частиц естественного радиационнго фона или воздействия сильных ЭМИ лучше применять МК с SRAM with HW parity checking...
Ну... или использовать частичную/полную проверку CRC ОЗУ имеющимися средствами в ходе работы проги, совместно с контролем настроек периферии...
Особенно следует уделить внимание циклам... циклам контроля флагов в частности... которые, вопреки утверждениям некоторых местных говнокодеров, легко, при определённых воздействиях, могут стать "вечными"...
Проштудируйте мануал и доки АРМинфоцентр на предмет исключений и барьеров... и про еррату не забудьте...
Избегайте сложных однострочных выражений, не пользуйтесь сомнительными и непонятными конструкциями... и т.д. , и т.д. , и т.д. ...

Короче... "ищите... и не взыщите"...

phenomen писал(а):Простите, но как вы бы решили проблему повисшего контроллера? Отключить и включить обратно питание? Или все-таки нажали бы кнопку ресет? Если есть МК, есть программа, значит есть и вероятность сбоя.

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

oleg110592 писал(а): Поставте дополнительный маленький микроконтроллер и посылайте ему по UART чего нибудь, если в течении какого то времени маленький не получил пакет, то сбрасывает большого. Маленький конечно тоже может зависнуть, но вероятность зависания уже меньше.

Добавлю чуток...
Мелкий МК лучше взять другой технологии... лучше и другого производителя...
Запитать от другого источника... или через RC-цепочку, при одном питании...
Вся фишка - в неравнозначности условий при возможном воздействии...

oleg110592 писал(а):Поставте дополнительный маленький микроконтроллер

HHIMERA писал(а):Мелкий МК лучше взять другой технологии...

Господа, для сброса контроллера применяеться внешний хардварный ватчдог, как писалось выше, например APX823. Этот в корпусе SOT23-5.

HHIMERA писал(а):Я бы отключил питание... секунд на несколько...

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

HHIMERA писал(а):Работа МК "по включению" и "по пересбросу" отличается... "Или нет?"(С)

А мне все-равно, и так инициализировать придется все с нуля.

HHIMERA писал(а):Ведь вам просто нужна "мэйжик кнопка"...

А как по вашему (в случае роутера) не зная его IP достучаться до него, может сбросить настройки той же кнопкой или выключить питание? На сколько выключить, на лет 100, пока информация из флеша сотрется? А просто сброс контроллера - дополнительная, обязательная фича.

HHIMERA писал(а):ничего общего с отказоустойчивостью не имеющая...

Представьте ситуацию: глубокая ночь, Вы крепко спите. А тут ваше устройство не отвечает ни на какие запросы. Что я бы сделал имея ваше устройство:

1. Познонил бы Вам и спросил совета что делать. Даже в 3 часа ночи. Ведь очень надо
2. С утра пораньше позвонил и высказал бы свое недовольство.

Естественно, Ваша карма при этом никак не растет.
Рассмотрим другую ситуацию
...ваше устройство не отвечает... минуту... две... И о чудо, благодара вачдогу все снова в порядке.
Рассмотрим третью ситуацию.
...ваше устройство не отвечает... минуту... две... Я подхожу к устройству и вижу межик кнопку ресет. Естественно я ее ткну перед тем как звонить Вам.

А за SRAM with HW parity checking... спасибо, посмотрю. Но думаю что немного перебор

phenomen писал(а):Представьте ситуацию: глубокая ночь, Вы крепко спите. А тут ваше устройство не отвечает ни на какие запросы. Что я бы сделал имея ваше устройство

Даже в страшном сне... не могу представить... и это при серийном выпуске!!!

Естественно, Ваша карма при этом никак не растет.

Это сколько-сколько... в вечнозелёных???

устройство не отвечает... минуту... две... И о чудо, благодара вачдогу все снова в порядке.

Гы... чудо оставьте себе... оно вам пригодится...

устройство не отвечает... минуту... две... Я подхожу к устройству и вижу межик кнопку ресет.

И какие слова вы скажите... когда надоест нажимать???

Господа, для сброса контроллера применяеться внешний хардварный ватчдог, как писалось выше, например APX823

А если ваш микроконтроллер начнет при зависании дергать ногой WDI, допустим программа попала в область настройки портов. Имхо микроконтроллер надежнее - тут можно и по UART + время + дополнительно дергать ногой. Причем поставить однократный пик - они неубиенные как показал опыт - пробовали стирать мощным гамма излучением - ни одна ячейка не стерлась.

По этому планируется завести IWD МК и дергать его в той части программы, где проверяется состояние ножки ресета