"Правильный" софт ресет, который почти как хард ресет Опции

[UniBomb]

Добрый день. Подскажите пожалуйста, как правильно сделать софтресет, а то возникла такая проблема:

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

Я так подозреваю, что дело в стеке, т.к. там на этот момент могут храниться несколько точек возврата ну и какие-то левые значения, из-за которых начальные значения являются некорректныи. Посему хочу спросить - как сбросить стек? Как поведёт себя перифирия после повторной инициализации?

[МП41]

Естественно процедурой очистку оформлять не надо и делать при запрещённых перываниях. Речь идёт о том, что ресет делается из работающей программы, у которой уже в памяти что-то валяется. Программа сама фузы не меняет, поэтому вывод сброса входом не станет, да и с диодом отпадает вариант.

Сообщение отредактировал МП41 - Nov 12 2008, 14:40

[Сергей Борщ]

Речь идёт о том, что ресет делается из работающей программы, у которой уже в памяти что-то валяется.

Ну и что? И во время первого запуска после аппаратного ресета в памяти что-то валяется. Программа же не использует мусор, она сначала инициализирует переменные, а потом уже ими пользуется. И в стек она сначала кладет, потом вынимает. Зачем делать еще какую-то дополнительную "очистку оперативки"?

Программа сама фузы не меняет, поэтому вывод сброса входом не станет,

Зато станет входом тот вывод, которым вы хотели дергать ногу ресета.

[zombi]

Зато станет входом тот вывод, которым вы хотели дергать ногу ресета.

Должно все работать ведь если он стал входом значит ресет уже сработал

А вообще мне кажется проблема только в неправильной начальной инициализации стека,портов и перифирии. Возможно первая инициализация (по включению питания) происходит нормально т.к. после аппаратного сброса все регистры инициализируются начальным значением, чего нет при JMP.
Нужно по шагам проверить программу инициализации предполагая что в регистрах и портах не стартовые значения, ну и конечно CLI и инициализация стека в начале обязательно.
Сброс по WDT оч. прикольно, думаю должен решить проблему.

[Сергей Борщ]

ну и конечно CLI и инициализация стека в начале обязательно.

Снова спрошу - зачем это шаманство с дополнительной инициализацией стека в начале? Программа и так его где надо проинициализирует. Раз она работает после аппаратного ресета, значит стек инициализируется где нужно. Даже(!) если будут разрешены прерывания, то их контекст будет сохраняться в ОЗУ, там, где остался указатель стека от предыдущего запуска программы.
Запрещать прерывания перед инициализацией (в случае перезапука методом jmp) конечно нужно.

Должно все работать ведь если он стал входом значит ресет уже сработал

У вас есть уверенность, что перевод портов в третье состояние - заключительная стадия процесса ресета?

[zombi]

У вас есть уверенность, что перевод портов в третье состояние - заключительная стадия процесса ресета?

Полной уверенности нет.
Но раз процесс ресета пошел разве он может не завершиться???

[ARV]

Полной уверенности нет.
Но раз процесс ресета пошел разве он может не завершиться???

вполне может. сброс - процесс многоэтапный, для 51-ых я где-то встречал подробное описание всех стадий. так вот, скажем на первом такте при наличии нужного уровня RST происходит сброс регистров pull-up, на втором такте - сброс DDRx, на третьем - остановка таймеров и т.д. (порядок условный - мои предположения). поэтому, если не дождавшись этапа, когда происходит, например, остановка работы ядра контроллера, убрать RST - контроллер вообще может оказаться в неопределенном состоянии (недосброшенным). теоретически может даже зависнуть... но скорее всего процедура сброса просто не будет выполнена до конца: может не произойти переход на адрес 0000, но вся периферия сбросится и т.п. имхо, лучше не экспериментировать.

P.S. так же имхо, нет приложений, критичных к скорости программного сброса, так что нечего бояться времени срабатывания WDT.

Сообщение отредактировал ARV - Nov 13 2008, 07:53