Микроконтроллер стал внезапно перезагружаться. Точнее, не внезапно, а после строго определённых действий с оборудованием. Поскольку действия были связаны с включением/отключением нагрузки, я было решил, что дело в электромагнитной совместимости, но игры со схемой заземления эффекта не дали.
По совету друзей я решил посмотреть причину перезагрузки. В большинстве МК есть регистр, который показывает, в каком статусе произошла текущая загрузка. В PIC32 он называется RCON. Регистр не слишком информативен, но это уже кое-что. Особенностью отладки в этот раз было то, что МК был установлен в уже собранный шкаф, поэтому были проблемы с тем, чтобы подключить отладчик. Но посмотреть содержимое данного регистра можно было несколькими способами. Во-первых, после перезагрузки контроллер нормально работал, поэтому к нему можно было подключиться с компа через штатный интерфейс. Дописать команду выдачи регистра -- не проблема. Но у меня было кое-что получше. Разработчики электроники приделали LCD-экранчик, который выдавал текст. И я мог вывести содержимое регистра прямо на него -- это во-вторых. Так я и сделал.
Я ожидал увидеть после "внезапной" перезагрузки или "нормальный старт", или "brown-out старт", т.е. сбой по питанию. Однако вместо этого я увидел бит, сигнализирующий о том, что перезагрузка была вызвана программно. А когда у нас вызывается программная перезагрузка? Либо при срабатывании Watchdog-таймера, либо в тех случаях, когда МК сваливается в необрабатываемое исключение типа деления на ноль или микроконтролерного аналога access violation. Watchdog был, но он был настроен где-то минут на 15, поэтому я решил копать в сторону исключений.
Для этого в PIC32 есть целых два регистра -- адрес исключения и причина исключения. Адрес я и так примерно знал, а вот причина была очень интересна. Причина -- это число от 1 до 30. И мне надо было как-то вытащить из МК это число.
Я собрался вывести его на экранчик, однако обнаружил, что в состоянии исключения МК на экранчик выводить ничего не хочет (SPI). Тем более, он не смог бы вывести ничего на компьютер.
Тогда я подумал, что поскольку перезагрузка программная, то содержимое оперативной памяти может сохраниться. Я сохранил регистры по определённому адресу, однако после перезагрузки обнаружил лишь нули, увы.
И вот тогда-то я вспомнил, как смеялся над разработчиками, что они мне поменяли светодиод на пищалку. Я написал цикл, который через паузу включает и выключает эту грёбаную пищалку столько раз, сколько указано в регистре причины исключения. После этого я с удовлетворением услышал пять гудков.
В переводе на виндузятский это означало "access violation, memory could not be written". Обнаружить конкретную ошибку ещё только предстоит, но уже сейчас можно сказать, что это, по-видимому, что-то вроде выхода за границы массива.
Разгадка: zhz00.diary.ru/p220990558_chto-okazalos-v-chyor...
По совету друзей я решил посмотреть причину перезагрузки. В большинстве МК есть регистр, который показывает, в каком статусе произошла текущая загрузка. В PIC32 он называется RCON. Регистр не слишком информативен, но это уже кое-что. Особенностью отладки в этот раз было то, что МК был установлен в уже собранный шкаф, поэтому были проблемы с тем, чтобы подключить отладчик. Но посмотреть содержимое данного регистра можно было несколькими способами. Во-первых, после перезагрузки контроллер нормально работал, поэтому к нему можно было подключиться с компа через штатный интерфейс. Дописать команду выдачи регистра -- не проблема. Но у меня было кое-что получше. Разработчики электроники приделали LCD-экранчик, который выдавал текст. И я мог вывести содержимое регистра прямо на него -- это во-вторых. Так я и сделал.
Я ожидал увидеть после "внезапной" перезагрузки или "нормальный старт", или "brown-out старт", т.е. сбой по питанию. Однако вместо этого я увидел бит, сигнализирующий о том, что перезагрузка была вызвана программно. А когда у нас вызывается программная перезагрузка? Либо при срабатывании Watchdog-таймера, либо в тех случаях, когда МК сваливается в необрабатываемое исключение типа деления на ноль или микроконтролерного аналога access violation. Watchdog был, но он был настроен где-то минут на 15, поэтому я решил копать в сторону исключений.
Для этого в PIC32 есть целых два регистра -- адрес исключения и причина исключения. Адрес я и так примерно знал, а вот причина была очень интересна. Причина -- это число от 1 до 30. И мне надо было как-то вытащить из МК это число.
Я собрался вывести его на экранчик, однако обнаружил, что в состоянии исключения МК на экранчик выводить ничего не хочет (SPI). Тем более, он не смог бы вывести ничего на компьютер.
Тогда я подумал, что поскольку перезагрузка программная, то содержимое оперативной памяти может сохраниться. Я сохранил регистры по определённому адресу, однако после перезагрузки обнаружил лишь нули, увы.
И вот тогда-то я вспомнил, как смеялся над разработчиками, что они мне поменяли светодиод на пищалку. Я написал цикл, который через паузу включает и выключает эту грёбаную пищалку столько раз, сколько указано в регистре причины исключения. После этого я с удовлетворением услышал пять гудков.
В переводе на виндузятский это означало "access violation, memory could not be written". Обнаружить конкретную ошибку ещё только предстоит, но уже сейчас можно сказать, что это, по-видимому, что-то вроде выхода за границы массива.
Разгадка: zhz00.diary.ru/p220990558_chto-okazalos-v-chyor...