Как я могу сохранить некоторые данные до аппаратного сброса микроконтроллера?
Я работаю над одним из микроконтроллеров Freesacle. Этот микроконтроллер имеет несколько источников сброса (например, сброс монитора часов, сброс сторожевого таймера и...). Предположим, что из-за сторожевого таймера мой микроконтроллер сброшен. Как я могу сохранить некоторые данные непосредственно перед сбросом. Я имею в виду, например, как я могу понять, где был программный счетчик перед сбросом сторожевого таймера. С помощью этого метода я хочу знать, где у меня ошибка (другими словами, длительный процесс), которая вызывает сброс сторожевого таймера.
6 ответов
Большинство микроконтроллеров Freescale работают следующим образом:
- ОЗУ сохраняется после сброса сторожевого таймера. Но, вероятно, не после сброса LVD и, конечно, не после сброса при включении питания. Это в большинстве случаев совершенно недокументировано.
- MCU будет либо иметь регистр состояния, в котором вы можете проверить причину сброса (например, HCS08, MPC5x, Kinetis), либо у него будут специальные векторы сброса для разных причин сброса (например, HC11, HCS12, Coldfire).
Нет способа сохранить что-либо после сброса. Сброс происходит, и только после этого вы можете узнать, что вызвало сброс.
Однако можно зарезервировать часть оперативной памяти как специальный сегмент. После сброса при включении питания вы можете инициализировать этот сегмент, установив все в ноль. Если вы получите сброс сторожевого таймера, вы можете предположить, что этот сегмент ОЗУ все еще действителен и не поврежден. Таким образом, вы не инициализируете это, но оставляете это как есть. Этот метод позволяет сохранять значения переменных при сбросе. Возможно - это не очень хорошо задокументировано для большинства семейств MCU. Я использовал этот трюк по крайней мере на HCS08, HCS12 и MPC56.
Что касается счетчика программ, вам не повезло. Это сбрасывается без средств, чтобы восстановить его. Это означает, что единственный способ выяснить, где произошел сброс сторожевого таймера, - это утомительный способ старой школы постепенно перемещать точку останова вниз по коду, запустить программу и проверить, достигла ли она точки останова.
Хотя в случае современных микроконтроллеров, таких как MPC56 или Cortex M, вы просто проверяете буфер трассировки и смотрите, какой код вызвал сброс. Вы не только получаете ПК, но и видите исходный код языка Си. Но для этого вам может понадобиться профессиональная цепочка инструментов без Eclipse.
Две вещи:
- Напишите журнал! И вращайте этот журнал, чтобы сохранить последние 30 минут. или в любое разумное количество времени, которое вы считаете необходимым для воспроизведения ошибки. Там, где журнал останавливается, вы можете увидеть, что произошло прямо перед этим. Даже в устройствах уровня производства есть некоторый уровень регистрации.
- (Меньше, практично). Вы можете подключить отладчик практически к каждому микроконтроллеру и пройтись по коду. Вероятно, установите точку останова, которая достигается непосредственно перед входом в критический раздел кода. Некоторые IDE /uC позволяют иметь "точки останова", которые запускаются, когда определенные переменные содержат определенные значения. Отказ от ответственности: я не знаю, какой именно микроконтроллер вы используете.
В зависимости от вашего микроконтроллера вы можете получить Reset Reason, но получить предыдущий program counter (PC/IP) после сброса это невозможно.
Большинство современных микроконтроллеров имеют Watchdog Interrupt Вместо reset, Вы можете настроить сторожевое периферийное устройство для включения прерывания. В этом ISR вы можете проверить сохраненный контекст в стеке. (Вы можете воспользоваться помощью отладчика JTAG для проверки стека вызовов).
Существует несколько методов отладки, если ваш микроконтроллер не поддерживает вышеуказанный метод.
например, в простом while(1) На основе архитектуры вы можете использовать HW-таймер и перезапустить его после некоторого раздела кода. В Timer ISR вы будете знать, какая часть кода потребляет достаточно долго, чем таймер.
Даже если бы вы могли получить Счетчик программ до сброса, не рекомендуется было бы вслепую устанавливать счетчик программ на другой после сброса - так как, вероятно, была бы информация о стеке и куче, а также сами данные, возможно, также изменились.,
Это зависит от того, что вы хотите сохранить после сброса, определенного поведения или данных? Энергозависимая память может или не может быть очищена после сторожевого таймера (см. Таблицу данных uC), и вы сможете обнаружить сброс после проверки регистров сброса (снова смотрите таблицу данных uC). Обнаружив сброс и проверив энергозависимую память, вы сможете подготовить свой ОК к перезагрузке так, как вы предпочитаете после маловероятного события сброса. Вы можете создать глобальное значение и установить для него определенное значение в глобальной области видимости, а затем, если оно сбрасывается, сравнить его с ним при возникновении события сброса - если оно совпадает, можно предположить, что другая память также может быть такой же, Если энергозависимая память не является опцией, вам необходимо взглянуть на таблицу данных об энергонезависимых опциях, однако также желательно не выполнять постоянную запись в энергонезависимую память из-за ограничений записи.
Это написано в вашем руководстве.
Я не знаю этот конкретный процессор, но в большинстве микропроцессоров сброс сторожевого таймера - это мягкий сброс, то есть определенные регистры будут хранить информацию об источнике сброса, а иногда и причину.
Вам нужно опубликовать более конкретную информацию на вашем Freescale µC для правильного ответа.
Единственное надежное решение - использовать отладчик с возможностью трассировки, если ваш чип поддерживает встроенную трассировку команд.
У некоторых устройств есть возможность перенаправить тайм-аут сторожа на прерывание, а не на сброс. Это позволит вам написать обработчик сторожевого тайм-аута, очень похожий на обработчик исключений, и вывести или сохранить информацию стека, включая адрес возврата, который укажет место, где произошло прерывание.
Однако в некоторых случаях ни одно из решений не является надежным способом достижения вашей цели. В многозадачной среде или системе с обработчиками прерываний код, выполняемый по истечении времени ожидания сторожевого таймера, может не являться процессом, вызывающим проблему.