@sdv_sybork

В общем, длительное копание показало, что дело отнюдь не в схемотехнике, а именно в программе.
Включил Mspdebug в режиме симулятора, загрузил в него полученный *.elf файл, начал его гонять и... заметил, что после первой сработки прерывания (на данный момент оно одно-единственное - таймер А по сравнению с TACCR0) и выполнения его обработчика случается совершенно внезапный прыжок в адрес 0xffff, на котором система глохнет. Очевидно, что в железе происходит тоже самое, после чего наступает risit и все начинается заново. И как раз-таки этот прыжок может случиться совершенно произвольно: сразу через две команды после reti первого прохода обработчика прерывания, либо через еще сотню-другую тактов... но так или иначе все заканчивается таким вот "вылетом" регистра PC в 0xffff, совершенно внезапным. При этом, если запретить прерывания вообще, то этого не случается, но это совсем не выход, тем более в требуемом приборе.
Я думал, что где-то стек срывает (хотя чем, казалось бы, всего одна глобальная uint16_t переменная), наблюдал за шагами стека и его содержимым, но нигде не замечал ни резкого изменения стека, ни единого случая, когда бы он указывал на ячейку с 0xffff. Сделал ради того, чтобы проверить, NMI прерывание, (т.к. это единственный объект, на который падала тень - по адресу его вектора лежал как раз адрес 0xffff), но как вылет был, так и остался - в обработчик прерывания NMI указатель не попал ни разу.
Кто-нибудь может подсказать, что за глюк такой может быть? Уже голову сломал, сроки идут, а тут запнулся на такой тупой ошибке, которую не могу отловить. Или это нормальное явление для MSPGCC, такие финты устраивать?

Вернуться к обсуждению:
Косяки с тактированием от внешнего кварца Микроконтроллер

0