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

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

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

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

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

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

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


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

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

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

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

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

Сообщение отредактировал mantech - Oct 2 2015, 12:20

Ну так зависит от типа устройства. Если оно - хост и имеет 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 уже написали все, что можно

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

Есть готовый эмулятор флешки - от 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 платах сидят.