2 ТС - ваша задача в общем случае не решается вообще Винда может захотеть записать кластеры файла в любое место, полностью проигнорировав начальное содержимое FAT. И узнаете вы об этом только после того, как весь файл будет записан и вам придет новый образ FAT'а.
Практически этого скорее всего не случится, но теоритически может.

Так что вариант из сообщения 42 (со сквозной нумерацией) это похоже единственное решение, которое будет работать всегда.
Да, и резать по секторам (512 байт) слишком мелко - вполне достаточно по кластерам, сектора в них никогда не перемещаются на другое место относительно самого кластера

Прочесть 2-4 байта адреса из начала блока данных и записать остаток в FLASH по этому адресу сложно?

Вот этого и хтелось бы избежать, поэтому и выбран был MSD, как не требующий драйверов и специальных программ.
А программа для изменения настроек - так она одному из ста понадобится, тем более, что их мобно поменять с самого устройства (там есть TFT и кнопки+энкодер).

Нет. Вообще идея это на моя, я уже упоминал - AN-10866 от NXP для LPC1700. Лкгко гугглиться: https://www.google.co.il/url?sa=t&rct=j...Vbd7ac7IWCsjiIw
У меня это работает уже несколько лет в паре устройств на LPC1768, конкретно сейчас это делается для STM32F103.
Там, где у меня стоит STM32F407 и STM32F767 я этого пока не делал, там бутлоадер, или тоже USB но в хосте, грузится с USB-флешки, или с SD-карточки.

Нет, просто не очень хочется переписывать программу подготовки (шифрации) образа фирмваре, чтобы она еще разбивала на блоки и вставляла номер блока. Она у нас написана двано и использоуется (с разными парамтерами) для всех устройств.
Я понимаю, что ее так модернизировать тоже не долго , но тут "не долго", там "не долго" - в сумме накапливается много времени на все это. А как я уже упомянул - неправильные действия не приводят к фатальным последствиям, максимум - юзер потратит еще полторы лишних минуты, чтобы сделать все правильно.

P.S. Лучше подскажите еще такую вещь - куда сразу смотреть в доки по процам, чтобы понять нужен им или не нужен подтягивающий резистор на Д+? На то, может ли USB был и хостом и девайсом? или на OTG? Но у LPC1768 он OTG/Host/Device, а резистор требует.

Я вот с STM32F103 до этого дел не имел, а из тех что имел - он только LPC1768 нужен был.
В последние годы работал с SM32F407, L151, L467 - им всем он не нужен, так я и для F103 забыл его в пробный вариант платы поставить, пришлось допаивать.

Имхо - для юзера куда хуже пляски с бубнами с подключениями/отключениями устройства, отключение кеширования в диспетчере оборудования, какими-то манипуляциями да ещё и несколькими файлами да ещё в определённом порядке их.
И при этом ещё ничего и не гарантируется, что всё равно будет записано неправильно, так как никаких гарантий от винды по поводу порядка записи кластеров нету, хоть сколько Вы у себя отлаживайте и проверяйте, найдётся система где кластера будут писаться в неправильном порядке (хоть сколько это устройство не дёргай). И объясняйте потом юзеру что это он зря порылся в реестре и поставил какие-то опции, или поставил какую-то хитрую прогу кеширования взамен стандартной. В ответ Вас будут спрашивать: А почему другие программы работают нормально, а Ваша - нет?
Маты от "благодарных" юзеров Вам, как разработчику этого велосипеда, гарантированы.
Куда проще - запустить файлик и нажать в нём одну кнопку "прошить". А уж про настройки и говорить нечего.


На LPC17xx стирание сектора флешь занимает вроде около 100мс. В это время все прерывания запрещаются. Ну возможно что USB-протокол (и MSD) устойчив к таким ситуациям....

Да.
У меня таким образом сделано обновление прошивки, запись пользовательского скрипта и чтение-запись области eeprom памяти.
Что винда, что linux всегда все пишут последовательно...
Естественно при загрузке я сам заполняю MBR, FAT и DIR для каждого диска. Это всего-то 3 сектора по 512 байт.
В MBR указано что чило копий FAT=1, секторов на элемент таблицы FAT=1 и число элементов в корневом каталоге = 512/32, т.е. занимает всего 1 сектор, использую FAT12.
Размер кластера 2 сектора, т.е. 1024 байта.
Имя в DIR генерю тоже при загрузке причем с версией загруженного приложения, так: YAM-MAINSCRIPT Version 1_23.ldr (это типа файл прошивки)
Метка тома содержит версию загрузчика, а серийный номер диска = собственно серийному номеру устройства.
Все крутится на STM32F105-й и занимает 16 килобайт в загрузчике.
Для обновления прошивки типа удаляем средствами винды файл старой прошивки и записываем новый. Контроллер расшифровывает на лету прошивку посекторно и сразу пишет в область приложения. Естественно файл прошики из устройства не читается , вернее читается, но там одни нули...

У меня все точно также, разве что сектор=кластер=512 байт, ну и диск пока один.
Попробую разобраться с LUN, не пользовался им пока.
Это на каждый диск надо иметь MBR+FAT+Root.
Похоже, два диска через LUN даже проще чем два раздела на одном диске.

Все точно также, только для F103 загрузчик сейчас 6.5К, я для уменьшения не вывожу в нем ничего на дисплей.
На LPC1768 тоже 6.5К занимало: Total ROM Size (Code + RO Data + RW Data) 6568 ( 6.41kB)

YAM, щiро дякую!

C двумя LUN получилось великолепно, теперь и последний недостаток исчез.
Долго завозился - второй диске не виделся, его размер генерировался автоматом из рамера области памяти + бут-рут-фат, получалось 4К, а винда хочет от 8К.
Поставил размер руками, а незанятые кластеры в фате прописал бэдами.
Теперь оба диска показывают свои области памяти и свободное место на диске =0.
Еще раз спасибо!

Я рад что смог помочь...

Интересно - откуда берется ограничение на мин. размер диска 8К? Я в доках не нашел, везде только максимум упоминается.

Специально сделал диск 4096 байт, нет проблем...

Странно, я перебрал длину диска от 4К до 8К, т.е от 8-ми до 16-ти секторов (по 512), 8-15 - винда кричала что диск не форматирован, на 16-ти успокоилась
Впрочем, это ни на что не влияющая ерунда.



А меньше дает? Может потому что кластер у Вас =1024 байта =2 сектора а у меня кластер = 1 сектор = 512 байт?


По идеет, на мин. размер ораничение должно быть бут+рут+фат + 1 кластер для данных.