STM32F405: прошить 400кб за 10 секунд или быстрый UART-загрузчик заточенный под USB-UART, размером менее 4 килобайт

Целиком не планируется.
Моя первая статья про шлюз про старую схемотехнику, в ней есть ряд недостатков и ряд "маячков". Это такие закладки которые у специалистов сразу вызвали бы вопросы. Но только у тех кто знаком с темой моей статьи. Таким образом я хотел получить фидбек о том что кто-то знакомый с темой прочитал вдумчиво статью. Но они или не сработали или было им лень. Поэтому и упала мотивация продолжать кому-то, что-то про шлюз рассказывать.
Зато отлично сработал маячок на перфекционистов и прочих любителей придраться не поделу — я просто выложил до ката фотку платы с "топорной" разводкой — ну они и набежали.

В этой же статьи тоже есть "маячки", в том числе такие — это упоминания делфи, винапи, ну и до кучи я натянул манифест заставляющий даунгрейдить интерфейс до винды 98, хотя при запуске видно что используются фишки современной винды включая вин 7 которые видны сразу.
И уже нашёлся любитель покритиковать не глядя и не запуская ничего (извини чувак, честно извени, не хотел тебя аггрить).

А про будущие планы:
Я планирую начать потихоньку выкладывать технологии из шлюза:

1. Например хороший и качественный помехостойки детектор модуляции бит в формате FSK, который используется везде в голосовой обработке, от АОН и DTMF набора, до детекторов тонов и полноценном модеме для диагностики шлюза.
2. Так же планирую описать как минимум два способа расчёта нелинейных искажений и шума. Один из них очень вкусный — не использует FFT и можно запускать хоть на атттини и простой как валенок (но в рунете не встречал, вычитал на японском про него).
3. Ещё можно расписать поподробнее про фильтры, в плане простой и надёжной реализации без потерь качества обработки звука и что многие считают фильтры неправильно и вносят немного но искажений и как этого избежать.
4. Ну и можно выложить свои наработки компактного и грамотного парсинга АТ команд на скриптах подобных регэкспу.
5. Можно рассказать о нововедениях и багфиксах предыдущей статьи про шлюз.

Если что то заинтересовало то пишите что, с удовольствием поделюсь как будет время и желание. Ну и запросившего можно наплюсовать чтоб я смог понять что больше всего заинтересовало.

хех. Я изначально хотел выложить другой вариант загрузчика, GPRS размером в 10к, с всем лексическим феншуем: нормализатор одиночных символов, последовательностей символов, выделитель слов и фраз, преобразователь hex строк и чисел в значения переменных, с форматом похожим на регексп, очень простой в использовании. Ну и с толикой аппаратной чёрной магии когда аппаратура МК сама пишет в класс локфрии очереди.
Мне показалось всё это через-чур сложным и у меня проблемы с графоманством, да и разбить на несколько частей и выкладывать по частям тоже не удобно — быстро мотивация пропадает и забиваю посередине. Может привыкну к хабру и научусь нормально и кратко писать статьи тратя мало своего времени, тогда и опубликую и свои наработки.

Но есть вопрос: в чем проблема GPRS? я загрузчик делал как вспомогательный и особо на него времени не тратил, и случаев включения его было буквально пара штук клиентами и поэтому саму логику включения GPRS я не прорабатывал как следует.
Поэтому очень буду благодарен если поделитесь своими проблемами.

1. Чтоб прошивка не утекла мы всегда держим чипы залоченными. Залочка не просто отключает SWD, а при попытке обращения по SWD превращает чип в кирпич пока не выключишь питание.
2. Он тоже далеко не 10 секунд прошивает, а в ряде плат на этих ножках стоят нехилые кондёры и SWD заведётся на очень маленькой скорости.

да, но зачем? их штатный бутлоадер с завода отлично справляется и пишет даже быстрее — там подругому флеш устроена и работает существенно быстрее.

второй вариант,
но содержимое прошивки отправляется уже на стадии стирания до полного заполнения буфера (экономия ещё в 2 сек).
Но как стирание прошло начинается запись и по мере освобождения озу на мк, прога прошивки докидывает ещё данные и на этой стадии процесс идёт уже параллельно, мк прошивает и рапартует о том что до такого то адреса прошито и настолько занят буфер мк, и одновременно принимает новые данные, т.к. хост видит что сколько ещё можно дозакинуть.
Смотри на видео справа команду WR 0x080xxxxx yyyyy где 0x080xxxxx — адрес до которого дописал, и yyyy — сколько занято озу.
На видео же заметно что идёт рывок в начале (мк прошивает быстрее чем принимает новое), а под конец скорость падает.

сотая серия и четырёхсотая серия существенно различается по скорости стирания и прошивки.
Сотая серия как раз отлично работает с штатными, проблем с ней нет. В отличии от stm32F40x.
Как уже выше писали что программный усб далёк от совершенства, поэтому проще отдельную USB-UART микруху поставить.

Это всегда полезно и увлекательно пилить мозги таракана начиная

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

Такая лицензия даааавным давно, более 10 лет назад была куплена, почему именно такая никто уже не помнит. Её в принципе хватает. Я до сих пор использую наработки начала 2000ых на модном тогда делфи.

Поэтому я скопировал код использованных функций SPL в отдельный заголовочник, объявил их как static inline и добавил к каждой такой функции суффикс _inline, например GPIO_DeInit_inline. Так же заинлайнил все вызванные ими функции. Это сразу сократило код в разы.

При реализации приёма UART в прерываниях возникла проблема:
по умолчанию код находится во флеше и во время прошивки флеш памяти, шина флеша блокируется и исполнение останавливается полностью включая прерывания. И на скоростях выше 500к БОД это приводит к потере принимаемых из UART данных, т.к. время приостановки становится больше времени приёма байта. Поэтому функция обработки прерывания была вынесена в ОЗУ вот таким вот образом: ...