Ну так у SAM7S little endian. Все правильно. По младшему адресу - младший байт.
Если есть светодиоды на плате, то для визуализации процесса можно понатыкать в Cstartup.S поочередное зажигание. И посмотреть где оно стопорится.
Давайте последний проект, посмотрю.

Я так и думал, но как объяснить слудующее. Фрагмент дизассемблера:


А вот hex:


Дизассембляция сделана командой: arm-elf-objdump -h -S -C - то есть дамп, как я понимаю, уже должен быть с перевернутыми байтами?


Отличная идея! Сейчас приложу архив.

Тут как раз байты не перевернуты, а стоят в правильном порядке. Маленький экскурс в HEX файлы.
: - Признак начала строки HEX. Все строки должны начинаться с него.
10 - Размер строки в байтах. Считаются только полезные байты.
403C - Адрес с которого начинает размещаться строка.
00 - Код записи. 00 - значит строка с данными.
FE - Первый байт данных. Размещается по указанному адресу.
FF - Второй байт данных. Размещается по адресу (указанный + 1)
....
Всего байтов данных столько, сколько указанно после двоеточия.
<Последний байт в строке> - контрольная сумма.

Сейчас гляну.

Посмотрел.

1. У Вас приложение (в бинарик и HEX) начинается вот с этого кода

А векторов там нет.

2. Разберитесь сначала с ARM режимом, а то сразу и ARM и THUMB Вас запутывает.
Например, Ваш boot переходит в THUMB, а потом запускает приложение командой BL, а приложение начинается с ARM режима, и соответмтвенно ничего не работает.

3.

А причем здесь endian?
-h - Показать заголовок
-S - Показать исходный код

Указать тип разименования символов, например c, cxx ....
Причем тут endian? Радуйтесь, что у Вас litle-endian .

Вот смотрите... После сброса чип бутлоадеру в ARM-режиме. В стартапе бутлоадера после различных инициализаций и пр. происходит переход на main()-функцию, причем переход по инструкции BX, которая, суда по документации, переводит процессор в THUMB-режим.

Выходит, что приложение получает thumb-процессор?

Но как это может повлиять на расположение секций в памяти и в образе? Означает ли это, что все приложение, запускаемое бутом, нужно пересобирать c ключем -mthumb?

Если bootloader переводит процессор в thumb то и приложение должно быть ЦЕЛИКОМ thumb.
Поскольку процессор по ресету стартует в ARM SUPERVISOR и все исключения - а соответственно и обработчики прерываний, которые у Вас в Cstartup.S то-же работают в ARM - то запуск приложения ДОЛЖЕН производится в ARM режиме.
ВО ВСЯКОМ СЛУЧАЕ ПРИЛОЖЕНИЕ ПО ВЕКТОРУ ИСКЛЮЧЕНИЯ RESET (у Вас ӕто 0x00001000) ДОЛЖЕН СТАРТОВАТЬ В ARM SUPERVISOR РЕЖИМЕ. Конечно Вы можете делать все что угодно, но тогда подразумевается, что Вы точно знаете что делаете.
То есть, по крайней мере Вы должны из bootloader перейтив ARM SVC.

Прежде чем смешивать ARM и THUMB и в bootloader и в app разберитесь сначала с одним режимом. И ӕтот режим для Вас должен быть ARM.

А THUMB введете потом.
И вообще, у Вас что действительно есть необходимость в thumb прямо сейчас?
В конечном итоге, рекомендую оставить main() в bootloader полностью ARM и запускать приложение bootloaderом именно из ARM и именно в ARM приложения, а функции перепрошивки флеш можно и THUMB сделать.

BX вовсе не обязательно переводит процессор в Thumb, для этого должен быть установлен нулевой бит в операнде.