Контроллер at91sam9g20, компилятор keil 4.03, загрузчик атмеловский.

Компилирую, зашиваю, все работает.
Меняю значение одной переменной, опять компилирую, зашиваю. Перестает отвечать Usart.
При этом меняется размер бинарного файла, хотя переменная char и за диапазон не выходит.

С чем это может быть связано, с компилятором, с памятью, с загрузчиком?

Это может быть связано с чем угодно. Слишком мало информации. Отлаживать надо.

Могу с удручающе высокой вероятностью утверждать, что "с компилятором, с памятью, с загрузчиком" это НЕ связано. Связано только с тем, что Вы написали.

Меняете часом не "char n" на "char n = 123"?
На размер бинарного файла обращать внимание не стоит, ибо RW-секции в RVCT по умолчанию компрессируются.

переменная unsigned char num = 1;
меняю на unsigned char num = 2;
Меняется размер, но раз так и должно быть, значит не в этом дело. Больше изменений никаких, причем, если добавить еще одну переменную, то usart опять продолжает работать. Также была еще одна непонятная проблема, когда объявлял массив char непосредственно перед функцией его использующей, то у меня переставал нормально работать кодек jpeg(Даже правильнее не переставал, а просто сжимал картинку неправильно), но стоило изменить его размер и все начинало работать нормально. Только вот этот массив никак не используется при сжатии. Может все связано с тем, что некоторые массивы у меня очень большие, до мегабайта могут доходить и память под них неправильно выделяется?
Иногда помогает взять старый проект и скопировать в него основной файл с main.

Неправильно - это как? Сдается мне, что при работе вы где-то выходите за границы. Как вариант еще стека может не хватать.

А что можно сделать со стеком?

Посмотреть расход и увеличить при необходимости.

Обычно, если действительно хочется получить помощь, соискатель сообщает не только как объявляется переменная,
но и *где* объявляется, и как она используется. То есть увидеть бы кусочек кода, сказать чего б было проще.
Да и мысли излагать бы пояснее: зачем чего-то копировать в старый проект?

Вы, вероятно догадываетесь, что показанные Вами конструкции вида
"unsigned char num = 1;"
тыщи программёров использовали по стопицот раз и, стало быть, дело не в них.

Весьма не исключено, что Вы её, конструкцию, используете хитрым способом
и, например, отыскали баг линкера, связанный, скажем, с выравниванием или инициализацией статиков.

Только вот вероятность обнаружения багов линкера\компилятора очень мала.
99,9% - это баг программы, написанной топикстартером

на работоспособность usart вроде как влияли кеши, после того как отключил их в загрузчике, все стало работать. Также заметил, что некоторые переменные могут обнуляться, если в настройках компилятора поставить оптимизацию по времени.(Хотя и не понимаю как такое может быть, в программе нигде нет обнуления этих переменных). Если перед их использованием передать их по usart, то все выполняется правильно. Главное что я понял, так это то, что лучше не использовать никакую оптимизацию вообще.

Часто бывает, что на высоких уровнях оптимизации отладчик привирает, а программа работает как положено.
А ещё часто бывают ошибки в программе, которые проявляются только на высоких уровнях оптимизации (обычно это вызвано нехваткой volatile в нужных местах).

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

Я плакалъ . Очередному пришла светлая мысль о том, что компиляторы пишут идиоты и оптимизациия вредна. Как не печально для Вас, но дела обстоят с точностью до наоборот.

Действительно парадоксальный вывод.
Вы просто не умеете их готовить.
Снижать уровень оптимизации в надежде скрыть ошибки в коде - это недальновидная стратегия. Эти же ошибки могут вылезти и по другим причинам. Вообще-то разработчики наоборот стараются сделать так, чтобы на этапе разработки вскрылось как можно больше багов. Для этого включают всякие предупреждения компилятора и даже - о ужас! - устраивают разнообразные стресс-тесты, чтобы отловить изъяны в системе.
Вы же подобно страусу прячете голову в песок в надежде, что баги пройдут стороной. Не пройдут.