С чего бы мог появиться такой эффект?

Независимо от того, на ввод или на вывод сконфигурирован порт B, при выдаче на какой-либо из его пинов лог.1 наблюдается меандр (не 50%) с периодом около 16 мс (62 Гц). Если это выход, то меандр чёткий, если вход - то завален спад. Сначала грешил на неправильно сконфигурированные T/C, но потом сократил программу до 5 строчек, только инициализация портов, ничего лишнего. Отпаял всю периферию. Причём, до этого схема на столе жила несколько дней, программа довольно большая, половину отладил. Аналогичное по схемотехнике устройство уже больше года работает у заказчика... И при том при всём кристалл без проблем прошивается (AVReal).

В общем, я так понимаю, что это кирдык атмеге? Менять её? Но с чего только...

Умерло всё в тот момент, когда я просто наслаждался отладочной инфой на индикаторе.

Может, устройство всё время выполняет RESET? Попробуйте поиграться с уровнем BOD, отключайте его, проверьте уровень питания, исправность блокировочных конденсаторов.
PS: А как себя ведут другие порты?

Может watchdog ?
И верифицируйте программу, на всякий - как-то я m128 как m8 несколько раз прошивал - эффекты были презабавные.

Точно на всех пинах PORTB?
Там в альтернативных функциях имеем spi и выходы таймеров.
Еще, как сказали уже, покопать в сторону перезагрузки.

Все три ответа в точку. Спасибо большое. Переработался, наверно - забыл на Reset глянуть.. Действительно перезагружался всё время. Слетели fuse... Вот как их раскорячило:

Fuses
OSCCAL = A6, A6, 9D, 9B
BODLEVEL = 0
BODEN = 0
SUT = 0
CKSEL = A
BLB1 = 3
BLB0 = 3
OCDEN = 0
JTAGEN = 1
CKOPT = 0
EESAVE = 1
BOOTSZ = 0
BOOTRST = 0
M103C = 0
WDTON = 0

А вот что было изначально (и теперь восстановлено):

BODLEVEL=1,
BODEN=0,
SUT=3,
CKSEL=f,
CKOPT=0,
EESAVE=0,
M103C=1,
WDTON=1,
OCDEN=1,
JTAGEN=0,
BOOTRST=1

А я было начал с того, что решил, что вылетел LCD, частично выпаял... Нет, в выходной надо отдыхать, а ночью - спать!

Если FUSE слетели во время работы программы, значит что-то не то с питанием. Или с выходными цепями МК у Вас непорядок.
Мега управляет какой-то мощной нагрузкой?

Скорее всего, я создал проблему с питанием. Как раз незадолго до слетания fuse-бит, и, возможно, именно в тот раз, я включил уже подключенный к схеме источник (не тот, с которым она будет работать) тумблером на входе источника. В итоге там было огромное время нарастания питающего напряжения (секунда-две). Хотя, наверно, в тот момент контроллер всё ещё работал, затем я его перепрошил и увидел, как гаснет индикация (уменьшается контрастность) на LCD (двустрочник символьный). А индикация на дисплее, возможно, осталась от работы предыдущей версии программы.
Такое питание могло быть причиной? (Хотя BODEN-бит был включен).
А мощной нагрузки пока ещё никакой нет, отлаживаю голый контроллер.

Фузы сами не слетают. Вы их программатором убили.

Возможно, что и программатором. Мне пока не ясен механизм того, как это могло произойти. Fuses я обычно прошиваю один раз, и в течение всей отладки про них не вспоминаю.

Так вроде Мега перестала работать во время любования отладочной информацией, как Glide сообщил.

PS. А вот и подтверждение автора вопроса.

Берем LPT шнур подлиннее, обматываем им UPS с подключенной нагрузкой ~1кВт, подключаем один конец к компу, второй через переходник (без буфера) к девайсу который хотим шить. Начинаем процесс загрузки прошивки. В процессе прошивки колбасим UPS (включаем/отключаем от сети). Проверяем результат после такой прошивки (как правило слетит все).

Может есть что-то общее между, так сказать, Environment'е Вашем и вышеприведенным примером?

Короче, чтобы не ходить вокруг да около - произошло это достаточно тривиально - в процессе загрузки или верификации прошивки исказилась 1 или несколько команд, что и убило фузы. Из правила "Обычно прошиваю один раз" тоже могут быть исключения:
- поставили где-то галку "шить фузы",
- написали батник с командой "шить фузы"
и забыли об этом.

Окружение - комп, LCD-осцилл и блок питания. В батнике ни слова про фьюзы, так что тоже вряд ли. Ну да ладно. Кабель адаптера около 80 см от LPT порта, после буфера буфера ещё сантиметров 15, так что можно предполагать, что всё-таки случилась какая-то помеха при программировании. Тем более, что процентах в пяти, наверно, ATmega шьётся неверно (иногда не проходит верификация).

Это оно - это и есть причина слета фузов! И это опасно - т.к. чип можно загнать в глухой угол из которого он уже не выйдет.

Попробуйте найти кто виноват! - локализовать источник помех, если его нельзя устранить тогда -поменяйне шнур, адаптер / БП.

Пока ни разу не загонялись в такое состояние, из которого не возвращались малой кровью. Были ситуации, когда в "полевых" условиях приходилось прошивать, и получалось, что не прошивались в 95% случаев, но в итоге, на 20-й раз, программирование проходило, и всё работало. Но, конечно, это не дело, - всё должно работать надёжно. Возможно, просто перейду на USB-программатор, т.к. уже была ситуация, когда под рукой только бук без LPT, и нужно что-то прошить.