Скажем так, не проблема пользователя прошивать через задницу, а выход из сложившейся задницы при вышедшем из строя uart. Вот если бы uart работал, то эти действия можно назвать "прошивка через задницу". Кстати во всех лоадерах: 1.2, 1.3, 1.5, 1.6, 1.7 начало E9 03 00 00, а дальше данные меняются. Нет возможности сейчас посмотреть что находится в лоадера, который я вчера залил. Позже напишу.

посмотрел я байты своего лоадера, первые 4: E9 01 02 40 - это прошивка для флешки 4 МБ, но и поглядел байты лоадера того же проекта, только для флешки 1 МБ и сравнил, в итоге получилось, что они отличаются друг от друга только вторым и третьим байтом, а остальное тело лоадера идентично. 1 МБ - E9 01 03 20, для 16 МБ: E9 01 02 90. При переводе из шестнадцатеричной системы исчисления в десятичную данные числа не представляют ни какого значения, похожего на объём флешки. Возможно в этих байтах задано некое смещение (адрес) по которому указываются параметры флеш. Но эксперимента ради сегодня вечером попробую прописать эти байты в лоадер из конструктора и проверю показания set size.

В этих двух байтах хранятся настройки режимов и размер флехи. За настройки отвечают определенные биты в них

теперь бы разобраться, что из них что. скорее всего 02 и 03 это режим, а 20, 40, 90 это размеры.

вот я ос.., забыл совсем, что ртос у меня корректно всё определил. посмотрел я лоадер ртоса из конструктора и 2, 3 байты: 02 40. Похоже загадка начинает разгадываться.

не мог найти более полноценное описание этих байтов, отрыл из исходников прошивальщика вот что:

задается массив static const char* flash_size_str[] = {"512K", "256K", "1M", "2M", "4M", NULL, NULL, NULL, "8M", "16M"};

и потом идет смещение на 4 разряда(умножение на 16)

т.е. чтоб задать размер 4мб ,то требуется ввести 4х16=64 , что равно 0х40 в хексе
Для 1мб получается 2х16=32 = 0х20

В младших битах этого байта еще задается частота .