Здравствуйте!
Программа откомпилирована в IAR C 6.40. Используются оба UART, кооперативная многозадачность. Одним словом, источников для неприятностей масса.
Механизм кооперативной многозадачности хорошо отработан. Его использую давно и без проблем. Неприятность возникла, как обычно там, где её не ждал.
Когда производится запись числа в EEPROM, программа дурит. Когда записывал 32-разрядное long int, то программа зависала. Когда процесс разбил на части
(пишу побайтно), зависать перестала, но некоторая дурь сохранилась. Вроде бы не может ничего такого сделать процесс запись в EEPROM. Самое худшее,
что он делает - тормозит программу, сканируя бит готовности EEPROM. Сетую на то, что один UART работает в режиме пассивного слушателя, а не в режиме
запроc / ответ. Можно предположить, что за время записи в EEPROM в буфер UART накидали что-то, сбилась синхронизация... Может быть у кого-то есть
ещё соображения на этот счёт? А ещё, может быть, у кого-то есть фрагмент кода, который позволяет производить запись в EEPROM, с использованием
прерывания, вместо сканирования бита готовности?
Заранее благодарен!

Может дело в том, что строб записи EEWE должен быть активирован не позднее 4 тактов после EEMWE.
Посмотрите внимательно порядок записи EEPROM в даташите.
Атмел рекомендует запретить прерывания на время записи.
А у Вас многозадачность...

Вы сами пишете или используете возможности IAR?
Квалификатор __eeprom long long int не помагает?
Дабы не происходило ничего непредвиденного во время записи в еепром попробуйте на время записи запретить прерывание __disable_interrupt()

IAR отключает прерывание при записи в EEPROM. У меня была проблема с ATMEGA8535. ATMEGA32 работает. 8535 упорно не хочет писать. По листингу вроде все нормально. Я тогда плюнул и заменил кристалл на 32 мегу. Для 8535 нужно функции на асме писать. А я этого в IAR не умею. Нужно как-то уметь, чтобы асмовская функция принимала значения из си кода.