ATmega32, IAR 4.12A и 4.21A (картина идентична). Модель памяти - small, RSTACK и CSTACK довольно большие и на ситуацию не влияют.

Обработчик прерывания по таймеру получился достаточно длинным. При дописывании очередного фрагмента к обработчику, в основной программе начинаются глюки. Исследования показали, что возникновение глюков не связано с тем, что именно дописываешь, работа нарушается при превышении некоего "объёма".

Как диагностировать происходящее, и как исправить ситуацию ?
Спасибо.

Сделать обработчик как можно короче. Все лишнее в фон.

Это способ обойти проблему, не всегда это возможно. Интересует "физика" процесса, что, собственно, не так ?

В начало обработчика вставляем команду "дернуть ногой вверх". В конец - "дернуть ногой вниз". Запускаем программу, смотрим осциллографом, синхронизация по фронту. Пока система успевает - "вверх" будет стоять на одном месте и между "вниз" и следующим "вверх" будет свободное место. Вольтметром можно измерять загрузку системы Как только "вверх" начинает дергаться - все, приплыли. А как исправить - _Bill абсолютно прав. Причем делать это надо было сразу, не дожидаясь пока программа глючить начнет.Это способ не породить данную проблему. Если не получается - значит надо увеличивать тактовую частоту ядра или брать другой (более скоростной) процессор. Или перекраивать алгоритм.Да не успевает процессор обработать прерывание до возникновения следующего. Можете еще так проверить - в конце обработчика проверить флаг этого прерывания - не взведен ли он уже. Если взведен - дергайте ногой. Осциллографом увидите дерганье в моменты, когда система не успевает.

В обшем смысле , какого либо лимита на длину обработчика прерываний нет. Ограничения вытекают из специфики задачи частоты прерываний и т.д.
Глюк так же может быть связан с обрашением к памяти которую использует основная программа . В таких случаях делают атомарный доступ типа запретить прерывания, обратиться к памяти, разрешить прерывания а в случае с РТОС и другие механизмы .

К сказанному Сергеем можно добавить второй индикатор который устанавливается в самой программе и дергает другую ножку . Меняя его место в основной программе и смотря двухканальным осциллографом можно локализовать проблемный код .

Слишко мало информации, чтобы поставить "диагноз". Причин могут быть десятки.

Обработчик успевает отработать до возникновения следующего прерывания. Задача как раз формировать сигналы на ножках и считывать ответные реакции. Периодичность возникновения прерывания - 5 мс, обработчик занимает 2 мс, что я и вижу на осциллографе (по этим самым формируемым сигналам). Основной программе остаётся 3 мс, вроде бы никакого криминала. В основной программе информация через UART отсылается на PC (и она действительно отсылается). Т.е., почти всё работает. Единственное, что становится не так - printf, выводящий в основной программе несколько сообщений на LCD, начинает печатать ерунду (как будто начинает брать информацию "не оттуда").

Добавьте стека и в RSTACK и в CSTACK

Зависит от задачи. Ты прекрасно знаешь товарища, у кого половина проектов работают в прерываниях, а main просто поражает своей мощью

Спасибо всем откликнувшимся. Проблема, как и следовало ожидать, оказалась вовсе не в обработчике прерывания. В основной программе была пропущена задержка после отправки команды очистки экрана на LCD. В зависимости от объёма обработчика прерывания, прерывание или "попадало" в нужное место (и обеспечивало задержку), или не попадало...