В своём посте чуть выше я писал, что содержимое функции инициализации LCD вообще не имеет значения. Я именно закомментировал ВСЕ строки в этой функции, оставил только вход и выход, и получил зависание. Я сам в шоке
Дело даже не в работоспособности/неработоспособности LCD в устройстве при отладке. Даже без функции инициализации всё работает на ура! При этом сама функция весьма простая, я её выкладывал. Просто - чудеса (он в чудеса не верит), я бы сам не поверил.

Сообщение отредактировал SerSh - Jun 27 2013, 08:28

Получается (если рассматривать программу в кодах ассемблера) что нерабочая программа отличается от рабочей наличием всего двух команд call XXXX и RET по адресу XXXX.
Это ж бред.

Вы сильно всё упростили.
Выполнение некой функции занимает определенное время. Убрав вызов этой функции Вы измените временнЫе соотношения между наступлением неких событий. В коде присутствует некая ошибка, которая проявляется именно при наступлении определённых событий в неком, конкретном временнОм интервале. Меняя местами вызовы функций ТС изменяет эти временнЫе соотношения. На время тестирования устройства те самые "нехорошие" события разошлись во времени, но не факт, что через продолжительное время эти "нехорошие" события вновь не "сойдутся"...
Так что, по большому счету, перестановка местами вызовов функций проблему не решает. И дело здесь, возможно, и не в инициализации LCD вовсе. Хотя и в такой "обсосанной" со всех старон теме, как инициализация LCD, ТС умудрился "накосячить"... Если у ТС LCD на HD44780, то "невооруженным взглядом" видны отклонения в коде от DS - они остались после исправлений с направлением передачи данных по шине данных. Вероятно, кроме LCD в изделии присутствуют и др компоненты, с которыми взаимодействует МК. Возможны "косяки" и при работе с ними...
Заметил, что "баги" давольно "прочно" поселяются с частях программ, "кочующих" из проекта в проект годами. С трудом вериться, что в коде, "проверенном" не одним проектом, могут быть какие-то ошибки... Ан - могут ! Однажды я нашёл ошибку в коде "благополучно" применявшимся 10 лет ! Поиск в программе ошибок, связанных с временнЫм соотношением между наступлением неких событий - дело трудное и не предсказуемое по результату...

Вы думаете, что я не понимаю, что это похоже на бред?
В своём посте чуть выше я написал о своих опасениях на этот счёт. Как пишет Палыч, очень возможно, что сейчас купированные симптомы потом вылезут где-то в другом месте.
Что сейчас делать я не знаю, потому и обратился за помощью на форум. Я над этой проблемой ломаю голову уже третью неделю.
Я ведь уже всё главное в программе сделал, а там куча разного железа: заняты все СОМ-порты, SPI, все таймеры... (не буду загружать). Короче, я думал, что уже включу WDT, и всё. Включил и всё... пропало! Тут только всё и началось.
Если будет желание посмотрите сами на инициализацию. В комментах я отметил как было вначале, когда всё зависало.

У Вас SEI сразу после инита WDT и затем еще какие то иниты.
Прерывания не рано разрешаете?

Я бы привел работу функций взаимодействия МК с LCD в соответствие с DS. Не вникал в них глубоко, но бросается в глаза несоответствие DS HD44780 от Hitachi (в Вашем LCD какой контроллер используется ?) коду функций lcd_init и lcd_ready. Заодно и др функции проверить - я в них смотрел "одним глазом", Вы же - посмотрите внимательно...

P.S. Кстати - константы задержек для функции __delay_cycles в файле defines.h определены неверно (у Вас - целые, а требуются - unsigned long) - после цифирек добавить UL

Та же песня!
ATMega88 после интервала для срабатывания Watchdog происходит полное зависание контроллера, выводы переходят в z состояние и всё, прога не стартует заново.

Код был портирован из ICCAVR где нормально работал в AtmelStudio с WinAVR, где и начались чудеса.
Симптомы полностью соответствуют указанным ранее, питание в норме, BOD включен, BOOTRST в 1 и.т.д.

Upd

Нашел!
Если инициализация watchdog происходит перед вызовом "_delay_ms(100)" (это из delay.h от winavr),
то watchdog работает корректно, при превышении интервала происходит нормальный сброс контроллера.
Если инициализацию поставить после этой задержки, то сброс по watchdog не происходит, все виснет намертво!

Дальше разбираться не стал, некогда.

Когда код был под ICCAVR задержка там была реализована другим образом и проблем не возникало, инициализировать watchdog можно было в любом месте программы.
Думаю что это компилятор зараза! (Оптимизация стоит на -O2)

Сообщение отредактировал berberber - Apr 1 2015, 11:02

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

ТС, вам нужно сделать переменную в ОЗУ. И придумываем значение. Пусть будет 0xAA.

В начале программы делаем следующее: проверяем переменную. Если переменная не равна 0xAA, делаем то что и должны в начале программы, инициализируем переменные, ввод-вывод, устройства, устанавливаем значение 0xAA. Если переменная равна 0xAA, то в обязательном порядке заново инициализируем то, что должно инициализироваться, дисплей к примеру.

Поясняю: если происходит сброс по сторожевому значению, то в ОЗУ остались какие-то рабочие значения, из-за которых и происходит затык МК. Программа ведет себя так, как будто сброса не было. В ОЗУ остались установленные флаги, состояния. Работа с дисплеем у вас идет с опросом флага ожидания. И скорее всего, заглючивший дисплей после сброса - виновник зависания. Или еще какое устройство, которое инициализируется при включении устройства.

Готовьте коньяк для Сергея.

Сообщение отредактировал demiurg1978 - Apr 1 2015, 16:07

Коньяк на доказательства менять не стану, он мне ближе к сердцу

Проблема для меня потеряла актуальность, поскольку я ее обошел, но осадочек остался

Кому интересно, прилагаю упрощенный пример:
Если сперва идет задержка, потом инициализация watchdog, получаем полный висяк через 2 секунды.
Если их поменять местами, каждые 2 секунды происходит нормальный сброс через watchdog.

Чтобы подтвердить вину компилятора нужны как минимум листинги одного и второго вариантов.

добавлено:
А собака случайно принудительно не включена фузами? Тогда, возможно, она успевает сработать во время задержки и программа просто не успевает дойти до перенастройки собаки.

И кроме того, если предыдущий сброс был по собаке, то установившийся бит WDRF автоматически выставляет WDE. Это означает, что после сброса по собаке программа работает с включенной собакой с минимальным периодом в 16 мс. И если ее не перенастроить, через 16 мс произойдет повторный сброс. Что мы и наблюдаем, если до перенастройки стоит задержка много больше этих 16 мс - 2 секунды до первого сброса и потом постоянние повторные сбросы не доходя до выполнения полезных действий.



Итак, компилятор снова оказался не при чем, виноват оказался программист, невнимательно читавший документацию. Как и в 99,9% остальных случаев, когда обвиняют компилятор. Надо было насчет коньяка додавить

Вот это и плохо, что вы сейчас ее обошли не разобравшись. И когда-нибудь она опять всплывет.

Кстати, да. Если у вас перенастраивается сторожевой таймер, то Сергей Борщ прав.