Третий день в голове крутится идея. Прошелся поиском по форуму, понял, что эту мысль несколько раз тут осторожно высказывали, но никаких выводов за/против я не увидел. Итак:

Сделать свой загрузчик, который при загрузке проверяет условие, например состояние ноги. Если выбрана простая загрузка - передает управление по адресу с основной прошивкой. А если нет, инициализирует USB Mass Storage. В системе появляется накопитель с текущей прошивкой (данные по конкретному адресу флеш). Запись нового файла ведет к перезаписи содержимого флеш. Можно организовать настройку - только запись, это уже нюансы.

Теперь про сложности, которые я увидел:
1) Нужна ФС. Или ее эмуляция. FATFS, которую STM поставляет с Cube занимает около 20кб флеша, что для загрузчика многовато. Хотя, можно и пережить
2) Непонятно, как заставить ФС напрямую превратить последовательный блок данных в файл, чтоб он был виден на ПК. Тут есть решение в виде эмулятора ФС, но он read only.
3) ОС может жонглировать секторами и писать прошивку не сплошным потоком. Хотя, это решаемо, если использовать FATFS и писать в промежуточную область памяти, а после записи копировать файл функциями ФС. Минус - Надо в 2 раза больше флеша, размер прошивки уменьшается.

Предлагаю обсудить, насколько проблема решаема? Может быть, кто-то реализовал?

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

Это как раз понятно. Зная устройство FATFS, несложно слепить таблицу FAT так, чтобы она указывала на прошивку как на сплошной файл.


Достаточно перетасовать секторы, чтобы они шли по порядку (как бы дефрагментация). Для этого не нужно в 2 раза больше флеша. Достаточно буфера в ОЗУ размером с сектор.

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

А вот об этом я не подумал, спасибо

Сначала подумал, что обновление прошивки с флехи, воткнутой в хост контроллера, но потом понял, что девайс нужно подключать к компу, он увидится флешкой и надо переписывать туда новую прошивку..

Вопрос - нафига это нужно вообще, в принципе не понимаю, народ так упорно использует для перепрошивки компы, когда можно обойтись обычной флешкой... Вот зачем?
ЗЫ. Еще могу понять это, когда в МК нет хоста, но как правило, он есть уже почти везде. Сорри за оффтоп, если чего

Ну так зависит от типа устройства. Если оно - хост и имеет USB AF, то логично прошивать его с флешки.
А если оно в обычной жизни - девайс, то какой смысл воротить из него хост и вешать порт для флешки? Кстати, как вообще сделать 2 USB порта на 1 МК?

Никак, если есть только один, или мудрить работу с хабами.



Подавляющее число раз, это были железки либо с хостом или была СД-карта, с которой так-же прекрасно перешивается мк

Само собой, если бы был хост или карты, такая идея бы не возникла)
Кстати, раз уж про карту заговорили: для считывания файла с карты ведь также нужна ФС на МК?

Вот, на русском и с картинками (но без кода):
http://easyelectronics.ru/proshivka-arm-co...-i-lpc1300.html

Вот готовая read-only библиотека:
http://geektimes.ru/post/254788/ (качество, правда, не смотрел).

Слова "Cube" и "FatFs" предлагаю забыть, взять большой напильник для этого emfat'а и сделать свой велосипед.


PS помнится мне, что ST уже сделала это в последней версии ST-Link'а. Где я это прочитал и где исходники - забыл...



У нас в одном изделии так и есть.
Понимание "почему так мало кто делает" наступает при попытках написать работоспособный хост. Желательно ещё и компактный (загрузчик же!).
У ST'шников в их StdLib получилось плохо. Правда, при обвешивании костылями как-то работает...


Абсолютно никак. FatFs - библиотека для обращения к файлам на внешнем носителе (флешка, карточка, NAND - да что угодно!). А тут надо решать обратную задачу: эмулировать носитель для "внешнего" устройства - ПК.

Неужели нет готовых библиотек?
Не в том плане, что мне лень сделать, просто у меня сложилось впечатление, что на STM32 уже написали все, что можно

Есть готовый эмулятор флешки - от ST (плохого, на мой взгляд, качества. но работает) и от libopencm3 (качество получше, код можно читать без мата).
Есть эмулятор файловой системы (см. ссылку выше); без него операционка на ПК предложит этот диск отформатировать.

Напильник для доработки файловой системы и рулон изоленты, чтобы всё это собрать - с Вас, я готовых решений в открытом доступе не знаю.

Само собой, или как вы предлагаете файлы читать

Все уже реализовано, например тут в YAM-TOUCH-CAP-V1A
Берем любой пример Mass Storage, пишем свои функции чтения и записи сектора.
При заходе в boot проверяем CRC приложения или нажатие кнопки.
Если в CRC ошибка или нажата кнопка запускаем инициализцию USB mass устройства.
При этом выделяем в ОЗУ память для 3-х секторов: MBR FAT и DIR.
MBR составляем так, что у нас 512 байт на сектор, 2 сектора на кластер (это для STM32F103C8T6)
1 резервный сектор который и есть MBR, 1 сектор FAT и элементов в корневом каталоге 512/32=16,
скрытых секторов 0. В качестве серийного номера тома я беру серийный номер изделия.
Далее заполняем таблицу FAT исходя из размеров прошивки или не заполняем если CRC ошибочна.
Заполняем DIR (или не заполняем если CRC ошибочна) нужным Вам именем файла с указанием начального FAT и размера прошивки.
В имя я всегда добавляю версию приложения, чтобы по имени файла можно было понять с чем имеем дело.
Т.е., например "YAM-TOUCH-CAP-V1 Version 3_06.ldr" такое имя будет у версии 3.06.
Так-же в DIR я заполняю VOLUME, где указываю версию загрузчика.
В чтении сектора если номер сектора меньше 3 отдаем то, что у нас в ОЗУ, иначе отдаем все 0
Давать читать прошивку не будем.
В записи сектора если запись в FAT или DIR - пишем себе в ОЗУ, иначе пишем в сектора приложения.
Операционка всегда (что windows, andoid...) пишет файл последовательно...
Весь boot у меня занимает 12288 байт...
Я конечно тут умолчал о том, что прошивка-то пишется зашифрованная и сначала сектора расшифровываются, а потом уже пишутся в область приложения.

Спасибо за наводку, сейчас буду разбирать.
Скажите, что будет в случае удаления файла с "носителя"?

А ничего не будет
Так как удаление происходит чисто для фенечки , т.е. для ОС, то при перезагрузке стартанет приложение (если с его CRC все в порядке).

p.s. А вот если начали писать файл и выдернули - то, соответственно CRC у приложения будет битой и девайс все время будет флэшкой пока не запишут корректно прошивку.

Именно так, собственно говоря, работает перепрошивка ST/Link'ов, которые там на всяких Discovery платах сидят.

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


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

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


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

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


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

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

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

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

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

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



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

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

Что-то Вы плохо ужимаетесь, как я писал, под 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
если это можно назвать библиотекой.