А еще такой вот тупой вопрос:
правильно я понимаю, что вызовы функций в слинкованном коде не относительные и линкер, который собирает прошивку, заливаемую через такой бутлоадер, должен знать смещение? Не получится сделать один файл, который будет шиться как самостостоятельно, через программатор, так и с подобным бутлоадером по другому адресу?


У меня STM32F4discovery, ничего такого не видел, поясните?

Сообщение отредактировал drozel - Oct 5 2015, 10:44

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


Я специально ничего не делал, чтобы увидеть MassStorage-проявление, но наблюдал: когда новый драйвер решает актуализировать прошивку в ST/Link, он чего-то там делает, после чего РС характерно трезвонит по причине пересоединения USB устройств, и я подглядел, что появляется и через некоторое время снова пропадает Mass Storage.

Сообщение отредактировал KnightIgor - Oct 5 2015, 13:13

Я все собираю в IAR-e, в workspace 2 проекта - boot и appl которые совершенно независимо компилируются.
Они имеют общий файл flash_config.h в котором задаются их адреса расположения...


Ну и общий файл описания назначения ног...
Отдельно на Builder-е написан собиратель прошивки в bin виде с подсчетом CRC загрузчика и приложения для программатора и в криптованом виде для загрузки через mass storage (только приложение).

DATA у меня для сохранения настроек и т.д.

Присоединюсь к YAM в части, как собирается совместный проект загрузчика и приложения. Я делаю так же. Я бы даже так переформулировал: прикиньте к носу, сколько может занять загрузчик (по опыту в 16К можно вложиться), и размещайте приложение всегда с фиксированного адреса выше загрузчика. Этот адрес забейте и в загрузчик. Аминь, ибо распространяться на тему перемещения таблицы векторов я не буду.

Сообщение отредактировал KnightIgor - Oct 5 2015, 18:37

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

например удалённое перепрограммирование самой логики приёма по разным каналам, ведение версий, подъём именно рабочей копии - т.е. кирпич
получить вообще маловероятно. При этом ядро будет занимать код подъёма версии и обёртки над обработчиками прерываний.

Сообщение отредактировал kolobok0 - Oct 6 2015, 09:29

Титаническое - это оверлеи.
По остальным вариантам - можно компилить в секции с такими адресами, которых нет в железе.
а потом по разбору инструкций вычитать смещения рабочих относительно нерабочих



read only файлы - 6кб на libopencm3
эмулируется boot sector, корневой каталог и fat16

С стшным HAL не уложишься - много весит USB. Еле до 20 ужал, выкинув отладочный UART.

Сообщение отредактировал drozel - Oct 6 2015, 03:46

Что-то Вы плохо ужимаетесь, как я писал, под boot выделено 0x3000, т.е. 12288 байт.
Реально же он занимает:
9 030 bytes of readonly code memory
502 bytes of readonly data memory
5 614 bytes of readwrite data memory
т.е. всего 9532 байт... Остальное используется когда включаю отладку.
При включенной консольной отладке:
10 852 bytes of readonly code memory
484 bytes of readonly data memory
13 642 bytes of readwrite data memory
для boot в IAR максимальная оптимизация по размеру.

Пока приложение лезет в свой диапазон всегда максимальная по скорости.

Как я понял, исходники Вы не выкладываете.
Какую библиотеку USB Вы используете?

Нет, не выкладываю.
USB библиотека: Mass_Storage из stm32_usb-fs-device_lib или stm32_f105-07_f2_f4_usb-host-device_lib на сайте st.com
если это можно назвать библиотекой.