Error returned from avr gcc exe

Справка по опциям командной строки высвечивается командой:

В зависимости от причин ошибки могут быть разные. Либо утилита make вообще не запускается, либо в процессе обработки makefile выдаются ошибки наподобие «Системе не удается найти указанный путь.». Первое, что нужно сделать в таких случаях — попытаться найти причину ошибки. Если причина известна, то будет понятен возможный способ её решения. Рассмотрим возможные варианты.

1. Самый простой случай, когда make вообще не запускается:

"make" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.

Это сообщение сигнализирует о том, что операционная система не может найти утилиту make. Либо вообще не установлен тулчейн, либо по какой-то причине в системной переменной %Path% не прописан путь до утилиты make. Решение простое — убедиться, что установлен нужный тулчейн, где утилита make присутствует, и проверить, что в переменной окружения %Path% правильно задан путь для запуска утилиты make.

Для компиляции makefile-проектов для AVR (например, из библиотеки LUFA) нужен либо тулчейн WinAVR, либо AVR Studio, либо Atmel Studio.

2. В процессе работы make возникают ошибки. Нужно внимательно изучить выводимые сообщения, и по ним разбираться в причинах проблем. Самый частый случай — в системе установлено несколько разных тулчейнов, где присутствует утилита make.exe, и когда Вы выполняете команду make, то запускается утилита из не того тулчейна, который нужен.

К сожалению, в этом случае сообщения об ошибке утилиты make может быть не информативным, например:

Системе не удается найти указанный путь.

Найдите на жестком диске все исполняемые файлы make.exe, и если их несколько, то отредактируйте записи в переменной Path таким образом, чтобы make.exe нужного тулчейна запускалась в приоритете, т. е. чтобы её запись пути поиска находилась первой в списке путей.

Если у Вас установлено несколько версий WinAVR, то нужно удалить старые пути запуска из переменной окружения Path, чтобы оставить только пути до той версии WinAVR, с которой Вы сейчас работаете. Такое может произойти, если на компьютере переустанавливался WinAVR (например, раньше был WinAVR-20080610, а теперь стал WinAVR-20100110). Необходимо ОБЯЗАТЕЛЬНО очистить переменную окружения %Path% от старых путей, иначе пути включаемых файлов include будут вычисляться компилятором gcc неправильно. Нельзя допускать, чтобы старые пути WinAVR соседствовали в %Path% с новыми, даже если новые пути идут первыми. Например, из-за этого глюка я долго не мог разобраться, почему компилятор и линковщик никак не могут найти функцию eeprom_update_byte. Для проверки, какие реально включаемые пути использует компилятор (где он ищет h-файлы), используйте опцию -print-search-dirs (см. пункт 4).

Для быстрого переключения путей Path на разные версии WinAVR удобно использовать командные файлы с настроенной командой set на разные значение переменной окружения Path. Также существует очень удобная утилита Rapid Environment Editor site:rapidee.com, которая позволяет легко просматривать, изменять записи переменной Path, добавлять новые записи, изменять их положение в списке. Имейте в виду, чтобы редактировать системные записи переменной Path, необходимо запустить эту утилиту с правами администратора.

3. Изучать сообщение об ошибке нужно очень внимательно, чтобы понять причину проблемы. Вот еще один пример, где совсем не очевидно, что проблема кроется в отсутствии папки obj в корневом каталоге проекта.

c:asmlufa-LUFA-170418DemosDeviceClassDriverGenericHID>make
' [INFO]    :' Begin compilation of project "GenericHID"...
""
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

' [GCC]     :' Compiling C file "GenericHID.c"
avr-gcc -c -pipe -gdwarf-2 -g2 -mmcu=at90usb1287 -fshort-enums -fno-inline-small
-functions -fpack-struct -Wall -fno-strict-aliasing -funsigned-char -funsigned-b
itfields -ffunction-sections -I. -DARCH=ARCH_AVR8 -DF_CPU=8000000UL -mrelax -fno
-jump-tables -x c -Os -std=gnu99 -Wstrict-prototypes -DUSE_LUFA_CONFIG_HEADER -I
Config/ -I. -I../../../../LUFA/.. -DARCH=ARCH_AVR8 -DBOARD=BOARD_USBKEY -DF_USB=
8000000UL  -MMD -MP -MF obj/GenericHID.d GenericHID.c -o obj/GenericHID.o
Assembler messages:
Fatal error: can't create obj/GenericHID.o: No such file or directory
GenericHID.c:201:1: fatal error: error writing to -: Invalid argument
 }
 ^
compilation terminated.
../../../../LUFA/Build/DMBS/DMBS/gcc.mk:213: recipe for target 'obj/GenericHID.o
' failed
make: *** [obj/GenericHID.o] Error 1

После добавления папки obj в корневой каталог проекта ошибка исчезает.

См. также Q006 и Q015.

Для разборок с запутанными операторами условной компиляции (#ifdef, #ifndef, #else и проч.) удобно использовать директивы #warning «сообщение» и #error «сообщение». Они позволяют точно определить, какую ветку в исходном тексте компилятор просмотрел, а какую отбросил.

Когда непонятно, почему не включается какой-нибудь заголовочный файл, удобно воспользоваться опцией -print-search-dirs, которая показывает пути поиска компилятором файлов. Эту опцию можно добавить в makefile к общим флагам компилятора, например так:

ALL_CFLAGS += -print-search-dirs

Причина — пропущена точка с запятой в начале строки комментария. Комментарий при этом скорее всего на русском языке.

Пример:

make: *** No rule to make target `opendous-jtag.elf', needed by `elf'. Stop.
make: *** Нет правила для сборки цели `opendous-jtag.elf', требуемой для `elf'. Останов.

Исправление ошибки:

1. Открыть makefile текстовым редактором, найти строку «elf:». В этой строке будет прописано имя цели, например:

2. make ругается на отсутствие этой цели $(TARGET).elf. Проверьте, правильно ли задана у Вас переменная TARGET, она должна быть задана строкой наподобие:

# Target file name (without extension).

TARGET = opendous-jtag

3. Если цель у Вас задана правильно, то возможно ошибка в описании действий по обработке цели. Найдите в makefile место, где обрабатывается цель elf. Это может быть блок текста наподобие следующего:

# Link: create ELF output file from object files.

.SECONDARY :

 $(TARGET).elf

.PRECIOUS :

 $(OBJ)%

.elf:

 $(OBJ)
    @echo
    @echo $(MSG_LINKING) $@
    $(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)

Здесь % означает «любой текст». Обычно такой знак используется для задания файлов определенного типа, например *.c, *.cpp, *.o и т. д. В некоторых случаях (например, в тулчейнах Atmel) такой паттерн обрабатывается неправильно, и не может быть автоматически сопоставлен с целью $(TARGET).elf. Поменяйте «%.elf:» на «$(TARGET).elf:», получится следующее:

$(TARGET).elf:

 $(OBJ)
    @echo
    @echo $(MSG_LINKING) $@
    $(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)

См. также Q002 и Q015.

Пример:

------ Rebuild All started: Project: usbasploader, Configuration: default AVR ------
Build started.
Project "usbasploader.cproj" (ReBuild target(s)):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreRebuild" in file "C:Program FilesAtmelAtmel Studio 6.0VsCompiler.targets" from project 
"C:asmUSBasp-bootloaderusbasploader.cproj" (target "ReBuild" depends on it):
Using "RunCompilerTask" task from assembly "C:Program FilesAtmelAtmel Studio 6.0VsCompiler.Task.dll".
Task "RunCompilerTask"
C:Program FilesAtmelAtmel Studio 6.0makemake.exe -C "C:asmUSBasp-bootloader" -f "Makefile" clean all 
c:Program FilesAtmelAtmel Studio 6.0makerm.exe: cannot remove `*.o': Invalid argument
make: Entering directory `C:/asm/USBasp-bootloader'
rm -f usbasploader.hex main.bin *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s
c:Program FilesAtmelAtmel Studio 6.0makerm.exe: cannot remove `usbdrv/*.o': Invalid argument
make: Leaving directory `C:/asm/USBasp-bootloader'
make: *** [clean] Error 1
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreRebuild" in project "usbasploader.cproj" -- FAILED.
Done building project "usbasploader.cproj" -- FAILED.
Build FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Ошибку можно устранить, если в тулчейне Atmel Studio заменить утилиту rm.exe (обычно находится в папке c:Program FilesAtmelAtmel Studio 6.0make) на rm.exe другой версии, которую можно взять из пакета WinAVR (обычно находится в папке c:WinAVR-20100110utilsbin).

Пример:

USBtoSerial.c:1:0: error: unrecognized argument to -mmcu= option: 'ATmega32U4'
USBtoSerial.c:1:0: note: See --target-help for supported MCUs

Причина в регистре символов опции MCU, которая была указана через makefile (или через командную строку). В опции -mcmu тип микроконтроллера должен быть указан маленькими буквами, т. е. вместо ATmega32U4 нужно указать atmega32u4.

#это ошибочно указанный для avr-gcc тип микроконтроллера:

#MCU = ATmega32U4

#здесь тип микроконтроллера указан правильно:

MCU = atmega32u4

Часто задаваемый вопрос, который звучит примерно так: «Скажите пожалуйста, можно ли каким нибудь образом конвертировать проект, скомпилированный с помощью MinGW, в проект AVR Studio или в Atmel Studio?».

Здесь под «проектом MinGW» подразумевается обычный проект на основе makefile, который компилируется из командной строки командами make clean / make hex (и т. п.). Ответ на этот вопрос — можно, и довольно легко. Дело в том, и AVR Studio, и Atmel Studio ВСЕГДА использует для компиляции внешний компилятор gcc и среду компиляции на основе makefile (это называется тулчейн, он может быть установлен как отдельно в виде WinAVR, так и в составе Atmel Studio). Причем есть два способа такой компиляции — либо makefile генерируется для проекта на лету средой AVR Studio/Atmel Studio, либо подключается внешний makefile (это настраивается в свойствах проекта AVR Studio/Atmel Studio).

Таким образом, Вы можете, во-первых — подключить к проекту внешний makefile (возьмите его из «проекта, скомпилированного с помощью MinGW»). Однако такой makefile должен быть составлен по особым правилам (в частности, имя target должно совпадать с названием проекта), так что обратитесь к документации Atmel или сделайте makefile на основе готового примера. Это можно условно назвать «конвертировать проект MinGW в проект AVR Studio или Atmel Studio».

Во-вторых, если не подключать внешний makefile, то можно просто тупо посмотреть все опции, которые настроены в «проекте MinGW» (т. е. заданы в makefile), и создать аналогичные опции в среде настроек свойств обычного проекта AVR Studio (или Atmel Studio). Например, нужно задать такие же:

— тип процессора (обычно это опция DEVICE makefile).
— тактовую частоту ядра (F_CPU).
— библиотека для отладочного вывода printf (PRINTF_LIB и т. п.).
— настройка опций генерации кода gcc — оптимизация и т. д. (CFLAGS).

Второй способ трудно назвать «конвертацией», потому что проект Вы будете настраивать вручную, подсматривая опции для настройки в готовом makefile «проекта MinGW». Однако и тут ничего сложного в принципе нет.

При перекомпиляции проекта Atmel Studio выдает ошибку наподобие «Целевой объект «PreBuildEvent» пропущен из-за невыполненного условия; выражение (‘$(PreBuildEvent)’!=») равно (»!=»)», и проект не компилируется.

Это просто глюк IDE Atmel Studio, связанный с ошибочной обработкой пустого списка событий до запуска сборки проекта (Pre-build event). Глюк можно обойти, если добавить ничего не значащее событие, которое есть, но ничего не делает. Для этого откройте свойства проекта, перейдите на закладку Build Events, нажмите кнопку Edit Pre-build и добавьте в список Pre-build event command line командную строку наподобие sleep 0, нажмите OK, сохраните проект.

После этого проект будет компилироваться нормально.

Примерно так выглядит сообщение компилятора:

Build started 8.5.2015 at 16:09:30
avr-gcc  -mmcu=atmega168 -Wall -gdwarf-2 -DF_CPU=11059200UL -Os -fsigned-char -MD -MP -MT ms5535.o

 -MF dep/ms5535.o.d  -c  ../ms5535.c
../ms5535.c: In function 'ConvertCtoW5535':
../ms5535.c:73:1: error: insn does not satisfy its constraints:
(insn 118 65 66 12 (set (reg/v:SI 20 r20 [orig:65 C6 ] [65])
        (mem/c/i:SI (plus:HI (debug_expr:HI D#1)
                (const_int 4 [0x4])) [3 C6+0 S4 A8])) ../ms5535.c:52 874 {*movsi}
     (expr_list:REG_EQUIV (mem/c/i:SI (plus:HI (reg/f:HI 34 argL)
                (const_int 4 [0x4])) [3 C6+0 S4 A8])
        (nil)))
../ms5535.c:73:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.atmel.com> for instructions.
make: *** [ms5535.o] Ошибка 1
Build failed with 2 errors and 0 warnings...

Ошибка связана с версией компилятора avr-gcc, и устраняется обновлением, либо к откату до предыдущей версии.

Примерно так выглядит сообщение компилятора:

../usart.c:46:6: error: attempt to use poisoned "SIG_USART_RECV"
 ISR (SIG_USART_RECV)
      ^
In file included from ../usart.c:1:0:
../usart.c: In function 'SIG_USART_RECV':
../usart.c:46:6: warning: 'SIG_USART_RECV' appears to be a misspelled signal handler [enabled by default]
 ISR (SIG_USART_RECV)
      ^
make: *** [usart.o] Error 1
Build failed with 1 errors and 1 warnings...

Проект раньше нормально компилировался тулчейном WinAVR, и такая ошибка стала появляться при попытке компиляции тулчейном Atmel Studio. Проблема была решена возвратом к тулчейну WinAVR-20100110.

Примерно так выглядит сообщение компилятора:

avr-gcc  -mmcu=atmega328 -Wall -gdwarf-2 -DF_CPU=11059200UL -Os -fsigned-char -MD -MP -MT usart.o

 -MF dep/usart.o.d  -c  ../usart.c
../usart.c:47: warning: 'SIG_USART_RECV' appears to be a misspelled signal handler

Предупреждение стало появляться при переводе проекта с ATmega168 (настройка в makefile: MCU = atmega168) на ATmega328 (MCU = atmega328). Вот в этом месте кода возникало предупреждение (выделено жирным шрифтом):

//обработчик прерывания приема USART

#if ((defined (__AVR_ATmega8__)) || (defined (__AVR_ATmega168__)) || (defined(__AVR_ATmega328__)))
ISR (SIG_USART_RECV)

#elif (defined (__AVR_ATmega16__))

ISR (SIG_UART_RECV)

#endif
{
    rxbuf[inrx++] = UDR0;
    inrx &= RXBUF_MASK;
    rxtimeout = 0;
}

Ошибка связана с тем, что в подключаемом файле, где определены векторы прерывания процессора, по-разному даны имена векторов прерываний для микроконтроллеров ATmega168 и ATmega328. Для того, чтобы узнать правильное имя вектора прерывания, откройте файл avrincludeavrio.h тулчейна, найдите там строку с условием препроцессора, где проверяется тип процессора (в нашем примере надо найти __AVR_ATmega328__):

...

#elif defined (__AVR_ATmega328P__) || defined (__AVR_ATmega328__)

#  include < avr/iom328p.h >
...

Строка #include < avr/iom328p.h > укажет на заголовочный файл, где определены регистры и вектора прерывания для процессора ATmega328. Откройте файл iom328p.h, и в секции определения векторов прерываний найдите нужное имя вектора прерывания (в данном примере имя вектора приема USART будет USART_RX_vect):

/* Interrupt Vectors */

/* Interrupt Vector 0 is the reset vector. */

#define INT0_vect         _VECTOR(1)   /* External Interrupt Request 0 */

#define INT1_vect         _VECTOR(2)   /* External Interrupt Request 1 */

#define PCINT0_vect       _VECTOR(3)   /* Pin Change Interrupt Request 0 */

#define PCINT1_vect       _VECTOR(4)   /* Pin Change Interrupt Request 0 */

#define PCINT2_vect       _VECTOR(5)   /* Pin Change Interrupt Request 1 */

#define WDT_vect          _VECTOR(6)   /* Watchdog Time-out Interrupt */

#define TIMER2_COMPA_vect _VECTOR(7)   /* Timer/Counter2 Compare Match A */

#define TIMER2_COMPB_vect _VECTOR(8)   /* Timer/Counter2 Compare Match A */

#define TIMER2_OVF_vect   _VECTOR(9)   /* Timer/Counter2 Overflow */

#define TIMER1_CAPT_vect  _VECTOR(10)  /* Timer/Counter1 Capture Event */

#define TIMER1_COMPA_vect _VECTOR(11)  /* Timer/Counter1 Compare Match A */

#define TIMER1_COMPB_vect _VECTOR(12)  /* Timer/Counter1 Compare Match B */ 

#define TIMER1_OVF_vect   _VECTOR(13)  /* Timer/Counter1 Overflow */

#define TIMER0_COMPA_vect _VECTOR(14)  /* TimerCounter0 Compare Match A */

#define TIMER0_COMPB_vect _VECTOR(15)  /* TimerCounter0 Compare Match B */

#define TIMER0_OVF_vect   _VECTOR(16)  /* Timer/Couner0 Overflow */

#define SPI_STC_vect      _VECTOR(17)  /* SPI Serial Transfer Complete */

#define USART_RX_vect     _VECTOR(18)  /* USART Rx Complete */

#define USART_UDRE_vect   _VECTOR(19)  /* USART, Data Register Empty */

#define USART_TX_vect     _VECTOR(20)  /* USART Tx Complete */

#define ADC_vect          _VECTOR(21)  /* ADC Conversion Complete */

#define EE_READY_vect     _VECTOR(22)  /* EEPROM Ready */

#define ANALOG_COMP_vect  _VECTOR(23)  /* Analog Comparator */

#define TWI_vect          _VECTOR(24)  /* Two-wire Serial Interface */

#define SPM_READY_vect    _VECTOR(25)  /* Store Program Memory Read */

Осталось в проекте исправить код препроцессора, где проверяется тип микроконтроллера и подставляется правильное имя вектора прерывания:

//обработчик прерывания приема USART

#if ((defined (__AVR_ATmega8__)) || (defined (__AVR_ATmega168__)))
ISR (SIG_USART_RECV)

#elif (defined (__AVR_ATmega328__))
ISR (USART_RX_vect)

#elif (defined (__AVR_ATmega16__))
ISR (SIG_UART_RECV)

#endif
{
    rxbuf[inrx++] = UDR0;
    inrx &= RXBUF_MASK;
    rxtimeout = 0;
}

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

Как решить проблему, не прибегая к выключению отладки (опции -O0 и т. п.)? Иногда выключить отладку не представляется возможным. ИМХО самый простой способ — присвоить переменной атрибут volatile, тогда компилятор не будет её оптимизировать, и выделит для этой переменной отдельную ячейку памяти.

void placetimesectors (void)
{
   volatile u8 ss, mm, hh;
   RGB_t color;
   
   ss = BCDtoBIN(rtc.reg.ss);
   mm = BCDtoBIN(rtc.reg.mm);
   hh = BCDtoBIN(rtc.reg.hh & 0x1F);

Теперь переменные ss, mm и hh будут легко доступны при пошаговой отладки. Этот совет хорошо подходит для большинства компиляторов, как IAR, так и GCC.

Также для AVR GCC (начиная с версии 4.4) можно отключить оптимизацию для блока кода с помощью директивы pragma:

#pragma GCC push_options

#pragma GCC optimize ("O0")

//Код, где будет отключена оптимизация
...

#pragma GCC pop_options

Для функции можно отключить оптимизацию добавлением атрибута __attribute__((optimize(«O0»))), например так:

void __attribute__((optimize("O0"))) foo(unsigned char data) {
    // не модифицируемый компилятором код
    ...
}

Среда AVR Studio при запуске компиляции проекта выдает ошибку: avr-gcc: CreateProcess: No such file or directory. Проблема здесь в том, что AVR Studio не может найти тулчейн (компилятор avr-gcc.exe и утилиту make.exe). Возможные причины:

1. Тулчейн не установлен.
2. В переменной окружения %Path% отсутствуют пути запуска для avr-gcc.exe и make.exe.

Как исправить: нужно установить тулчейн. Тулчейн это либо пакет WinAVR, либо тулчейн, который можно скачать и установить в составе Atmel Stidio или отдельно. Если у Вас есть уже установленная копия тулчейна, то достаточно добавить в переменную %Path%. полный путь до утилит avr-gcc.exe и make.exe.

Возможно, что для некоторых все вышесказанное кажется абракадаброй. Поэтому если Процесс по шагам (на примере AVR Studio 4.19, Windows 7 64-bit):

1. Скачайте архив [1].

2. Распакуйте из архива папку WinAVR-20100110 на диск C:

3. На этом шаге надо настроить (или проверить правильность) путей поиска в переменной %Path%. Кликните Пуск -> Панель управления -> Система -> Дополнительные параметры системы -> Переменные среды… -> нижний список Системные переменные -> Найдите в списке строку с переменной Path и выберите её -> нажмите на нижнюю кнопку Изменить… -> Проверьте, что в строке ввода пути есть пути C:WinAVR-20100110bin (в этой папке находится avr-gcc.exe) и C:WinAVR-20100110utilsbin (в этой папке находится make.exe). После того, как внесли изменения, кликните OK, OK и еще раз OK.

Примечание: помните, что отдельные записи в переменной Path отделяются друг от друга точкой с запятой. Если Вы затрудняетесь с редактированием переменных окружения, то прогуглите этот вопрос, в Интернете полно материала по теме.

Примерно так должна выглядеть переменная %Path% после редактирования (это результат выполнения команды echo %Path%, добавленные пути выделены жирным шрифтом):

C:Python25;C:Python25Scripts;C:ProgramDataOracleJavajavapath;C:Program
FilesImageMagick-6.9.0-Q16;C:WinAVR-20100110bin;C:WinAVR-20100110utilsbin;
C:Program Files (x86)NVIDIA CorporationPhysXCommon;C:Program Files (x86)AM
D APPbinx86_64;C:Program Files (x86)AMD APPbinx86;C:Windowssystem32;C:W
indows;C:WindowsSystem32Wbem;C:WindowsSystem32WindowsPowerShellv1.0;C:P
rogram Files (x86)Common FilesAdobeAGL;C:Program FilesTortoiseHg;C:Program
 Files (x86)SecureCRT;C:Program Files (x86)SkypePhone;C:Program Files (x8
6)Atmelsam-ba_2.13drv;C:Program Files (x86)Atmelsam-ba_2.13;C:Program Fi
les (x86)Dev-CppMinGW32bin;C:Program Files (x86)AtmelFlip 3.4.7bin

4. Запустите AVR Studio, откройте проект, который у Вас компилировался с ошибкой. Откройте свойства проекта, перейдите в раздел Custom Options, снимите галочку Use AVR Toolchain, и с помощью кнопочек «…» добейтесь, чтобы для avr-gcc у Вас был путь:

C:WinAVR-20100110binavr-gcc.exe

и для make был путь:

C:WinAVR-20100110utilsbinmake.exe

Нажмите OK.

См. также Q002 и Q006.

Например, для ATmega16 следующий код скомпилируется нормально:

   out _SFR_IO_ADDR(TIMSK), R24

Но для ATmega328 подобный код выдаст ошибку «Error: number must be positive and less than 64»:

   out _SFR_IO_ADDR(TIMSK1), R24

Такая ошибка происходит из-за того, что сделана попытка обратиться к регистру SFR (регистр специального назначения, Special Function Register) командой in или out, при этом адрес SFR превысил значение 63. У регистра TIMSK1 адрес равен 0x6F (десятичное 111), что как раз адрес превышает 63.

Исправить ошибку можно, если вместо out применить команду sts (in заменяется на lds):