Стартап и скрипт линкера из CMSIS для Sourcery CodeBench Опции

[koluna]

Всем привет!

Помогите разобраться, пожалуйста.
Стартап и скрипт взял из CMSIS 3.01 (\Device\ARM\ARMCM3\Source\GCC): gcc_arm.ld, startup_ARMCM3.S (приложил к теме).
Подцепляю к простейшему тестовому проекту.
При сборке линкер ругался сначала на отсутствие libnosys.a (ее действительно нет в дистрибе компилятора) - убрал ее из списка в скрипте. Ошибка пропала.
Но так и не нашел, что это за либа, для чего нужна и почему ее нет...
Потом линкер ругался на отсутствие "_start". Странно, откуда эта метка в стартапе и почему так называется? Поставил вместо нее "main" - все собралось. Ошибок нет.
Но осадок сомнения остался - уже две ошибки в этих двух файлах... кто знает, что там еще? Надеялся, что все заработает "из коробки".
Пока не зашивал, не уверен в работоспособности, будем пробовать.
Насколько можно верить этим файлам? Что еще в них придется корректировать (ну, кроме размеров RAM, ROM, размеров стека и кучи)?

Прикрепленные файлы

 GCC.zip ( 3.82 килобайт ) Кол-во скачиваний: 14

 

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

Но у меня чисто теоретические познания в этой области, я не писал загрузчиков и приложений под них. Надеюсь, Сергей Борщ что-нибудь добавит.

Из описания VTOR:

Bits 29:11 TBLOFF[29:9]: Vector table base offset field.
It contains bits [29:9] of the offset of the table base from memory address 0x00000000. When
setting TBLOFF, you must align the offset to the number of exception entries in the vector table.
The minimum alignment is 128 words.

Собственно тут все сказано: выравнивание должно быть на 128 байт.

Как я понимаю, наш случай - предпоследний?

Нет. Но в двух словах: программа будет работать в железе и без строчки ENTRY(), ибо старт с вектора по адресу 0x00000004 в процессоре прибит гвоздями. Эта строка (в приведенном AHTOXой виде) нужна отладчику, ибо он не умеет (пока) брать стартовый адрес из таблицы векторов, а пытается, по старинке, считать код команды по адресу 0. А у Cortex там лежит начальное значение указателя стека и получается конфуз.

Кстати, атрибуты регионов здесь зачем?

К программисту подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Что, правда?
- Да.
- Каждый день?
- Да.
- По-другому было когда нибудь?
- Нет.
- О! Вот это работает - не трогай.

[AHTOXA]

Собственно тут все сказано: выравнивание должно быть на 128 байт.

Понятно, то есть, вариативность в описании от АРМовцев - это для производителей проца. А ST сделал жёстко 128 слов, убрав ещё пару младших битов у VTOR. С точки зрения написания линкерных скриптов это хорошо: надо просто поменять выравнивание с 4 на 512:)

работает - не трогай.

Именно!

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

128 слов

Да, виноват, ошибся. 128 слов, 512 байт.
Да я вам больше скажу: они там сами никак не определятся. На картинке замаскированы 9 бит, а полностью описание звучит так:

Bits 29:11 TBLOFF[29:9]: Vector table base offset field.
It contains bits [29:9] of the offset of the table base from memory address 0x00000000. When
setting TBLOFF, you must align the offset to the number of exception entries in the vector table.
The minimum alignment is 128 words. Table alignment requirements mean that bits[8:0] of the
table offset are always zero.
Bit 29 determines whether the vector table is in the code or SRAM memory region.
0: Code
1: SRAM
Note: Bit 29 is sometimes called the TBLBASE bit.
Bits 10:0 Reserved, must be kept cleared

Так все-таки 29:11 или 29:9? Судя по последующим "Bits 10:0" маскируются 11 бит и выравнивание должно быть на 2048 байт. "Ребус, краксворд!".

[AHTOXA]

Так все-таки 29:11 или 29:9? Судя по последующим "Bits 10:0" маскируются 11 бит и выравнивание должно быть на 2048 байт. "Ребус, краксворд!".

В PM0214 (Programming manual для F4) всё однозначно:

Bits 29:9 TBLOFF: Vector table base offset field.
Bits 8:0 Reserved, must be kept cleared

Видимо была опечатка в предыдущих PM.