IAR ARM линкер выдает R_ARM_THM_JUMP11 Опции

[megajohn]

LPC1114 + IAR ARM6.3
в проекте вырезал уже многое.
вот с чем борюсь

Код

u32 mem_arr[2];
memset( mem_arr, 0, sizeof( mem_arr ) );

работает

меняю размер на 3 и не работает =(

Код

Error[Lp002]: relocation failed: value out of range or illegal: 0xfffff7fe
     Kind    : R_ARM_THM_JUMP11[0x66]
     Location: 0x00000f58
               Module:  I:\projects\tetra\mcu\Debug\Obj\startup_LPC11xx.o
               Section: 17 (.text)
               Offset:  0x0
     Target  : 0x0000075b
               "SysTick_Handler"
               Module:  I:\projects\tetra\mcu\Debug\Obj\other.o
               Section: 8 (.text)
               Offset:  0x1f

памяти достаточно (ROM занято 3 338+52 из 32кб, RAM занято 5 744 из 8кб )
да и на отсутсвие памяти ругается как Error[Lp011]: section placement failed: unable to allocate space for sections/blocks with a total estimated minimum size of 0x2604 bytes in <[0x10000000-0x10001fdf]> (total uncommitted space 0x1fe0).
я так понял что при линковке не может вставит инструкцию JUMP до функции SysTick_Handler ?

на IAR ARM 6.6 тоже самое

гугль пока не помог

в мап-файлах ничего выдающегося не нашел
 2ok.txt ( 22.16 килобайт ) Кол-во скачиваний: 635
 3fail.txt ( 22.72 килобайт ) Кол-во скачиваний: 684

[Сергей Борщ]

Предположение: При изменении размера этого блока код становится больше (например, подтягивается библиотечный невстроенный memset) и какой-то вызов из startup_LPC11xx уже не может дотянуться до функции SysTick_Handler из other. Хотя это бред - обработчик же вызывается из таблицы прерываний, а там 32-битные адреса. Покажите листинг startup_LPC11xx. И кстати, если startup_LPC11xx написан на асме - то возможны варианты, а если на С/С++ - то это ошибка ИАРа, и надо писать в его техподдержку.

Добавил: Ан не-не-не. Это не вектор из таблицы - это некая команда из startup_LPC11xx размером 2 байта, которая после линковки попадает в адрес 0x00000f58 - вероятно какой-то короткий переход. Дизассемблер слинкованного можно посмотреть, что попадает в адрес 0x00000f58?

CODE

  .text               ro code  0x00000f52    0x2  startup_LPC11xx.o [1]
  .text               ro code  0x00000f54    0x2  startup_LPC11xx.o [1]
  .text               ro code  0x00000f56    0x2  startup_LPC11xx.o [1]
  .text               ro code  0x00000f58    0x2  startup_LPC11xx.o [1]
  .text               ro code  0x00000f5a    0x2  startup_LPC11xx.o [1]

[SII]

Тут сгенерирована 2-байтовая команда безусловного перехода B, и она не может дотянуться до цели (об этом говорит код перемещения R_ARM_THM_JUMP11). Вообще-то компоновщик должен бы сгенерировать т.н. veneer -- специальный "переходник", который расположен ближе к исходной команде (чтоб она могла до него дотянуться) и который выполнит переход уже на нужную команду. Но он почему-то это не делает. Почему -- без понятия, IARом не пользуюсь, да и на Си не пишу. Однако совершенно ясно, что здесь вызов идёт НЕ из таблицы векторов прерываний, где действительно 32-разрядные адреса, а именно командой B. Надо смотреть, как правильно сказали, startup_LPC11xx.

[megajohn]

Код

        PUBWEAK SysTick_Handler
        SECTION .text:CODE:REORDER(1)
SysTick_Handler
        B SysTick_Handler

 startup_LPC11xx_list.txt ( 20.58 килобайт ) Кол-во скачиваний: 292

 startup_LPC11xx_s.txt ( 9.02 килобайт ) Кол-во скачиваний: 170

[SII]

Ну, так и есть, эта самая команда B. Надо удалить эту пару строк, как и PUBWEAK SysTick_Handler, из файла; вместо последней вставить что-нибудь вроде EXTERN SysTick_Handler (что именно -- надо смотреть в документации на IARовский ассемблер) и убедиться, что в таблице векторов прерываний находится SysTick_Handler.

[demiurg_spb]

Ну, так и есть, эта самая команда B.

Можно переосмыслить на BX.

Похоже, что не надо, т.к. для ARMv7-M она позволяет достаточно далеко прыгнуть, фактически на 16МБ: -16777216 to 16777214
стр. A6-40 http://web.eecs.umich.edu/~prabal/teaching...ARMv7-M_ARM.pdf

[megajohn]

Предистория, нужно было перелезть с CM3 на CM0
смотрю стартап в иаровских примерах cstartup_M.s  cstartup_M_s.txt ( 7.41 килобайт ) Кол-во скачиваний: 663
и смущает запись отличная от CM3
ну думаю фигня какая, давай поишу стартапы похожие на CM3 - и нахожу таки в IAR6.6 файл startup_LPC11xx.s  startup_LPC11xx_s.txt ( 8.9 килобайт ) Кол-во скачиваний: 171
который и привел. Проверил тестовый проект работает, а своё перетащил и нефига =(

Вернул обратно cstartup_M.s и все работает
единственное, что default handler меня сбил столку, но в векторах все номано

[SII]

Можно переосмыслить на BX.

Можно, да, но размер кода чуть больше, чем если вектор обработчика прямо в таблице векторов лежит (когда вообще никаких команд для вызова не требуется).

Предистория, нужно было перелезть с CM3 на CM0

У Cortex-M3 реализована система команд Thumb-2, а у Cortex-M0 -- только Thumb. В последней нет 32-разрядных команд (не считая BL, которая изначально, ещё в версии ARMv4T, была "оформлена" как пара 16-разрядных инструкций), а поэтому с дальними переходами возникают проблемы. Правда, всё равно непонятно, почему компоновщик не сгенерировал veneer. Возможно, он просто не умеет это делать для Тумбы-1.

[demiurg_spb]

поэтому с дальними переходами возникают проблемы

Ваша правда!
У CM0 диапазон для B label поуже будет: −2KB to +2KB

http://infocenter.arm.com/help/index.jsp?t...a/CIHJJEIH.html

[Сергей Борщ]

Смущает другое - эта функция оформлена как PUBWEAK, т.е. должна была быть заменена на объявленную пользователем. В реальности же линкер выкинул только метку, но не содержимое этой секции (SECTION .text:CODE:REORDER(1)). Можно предположить, что следом должна была идти другая команда SECTION, начинающая другой участок кода, но она потерялась и линкер, используя метку из следующего кода был вынужден захватить и эту команду. И если исходно она должна была сделать переход сама на себя, то теперь она должна перейти на пользовательский обработчик, до которого уже не дотягивается.

Вообще, по моим понятиям порочный тут уже сам факт написания этого кода на ассемблере - весь этот файл легко пишется на С/С++

[megajohn]

Смущает другое...

тут еще косяк ИАРовский выявился в 6.3 при компиляции с флагами Multi-file Compilation и Discard Unused Publics выкидываются вектора ! Помог __root