Разрабатывается загрузчик A -загрузчика для замены существующего загрузчика Maple.

Улучшения в «Bootloader 2.0 "есть

• Вся оперативная память в процессоре доступна для эскиза для загрузки, чтобы Flash. В старом загрузчике 3K всегда выделяется на загрузчик, даже если загрузчик не работает после запуска эскиза, поэтому 3K не нужно зарезервировать
• "Bootloader 2.0 " - на 12 тыс. Меньше, чем старый загрузчик, так что для эскиза на 12 тыс. Больше для эскиза
• Загрузка на OSX и Linux должна быть намного быстрее

Текущий статус

Bootloader работает для Maple Mini, когда используется с последней версией Arduino STM32 из GitHub.
Вам также нужно выбрать «Bootloader 2.0 "из меню" версии Bootloader "в выборе Maple Mini Board.

Однако есть одна ошибка, которая должна быть решена. Загрузка в ОЗУ в настоящее время не работает.
Это связано с тем, что старая загрузка RAM может с периодическую срок службы в беге. Это связано с тем, что загрузчик пытается определить, содержит ли ОЗУ эскиз или просто переменные, а «магическое число», используемое для этой цели, слаб.

Я разрабатываю новую систему, которая использует 64 или, возможно, 128 -битное волшебное число, а не эффективное 13 -битное волшебное число, которое использовал старый загрузчик.

Роджер, я предлагаю просто изменить маску, используемую для фильтрации адреса SP в CheckUsercode в оборудовании.в

if ((sp & 0xfffe0fff) == 0x20000000) {

Это оставляет только 5 бит, которые покрывают диапазон от 4 кб до 64 КБ. Все еще может быть ложные срабатывания, но гораздо менее вероятно, что нынешний.

На самом деле, как насчет этого?

Кажется, компилируется для меня хорошо. Я не дома, поэтому у меня не было возможности проверить это.

#если определено (target_maple_mini)
if (sp == 0x20005000) {
#elif определено (target_maple_rev3)
if ((sp & 0x2ffe0fff) == 0x20000000) {
#endif

Виктор

Проблема не в двух разных версиях доски.

Проблема в загрузке в ОЗУ

Когда загрузчик сбрасывает себя после загрузки в ОЗУ, он должен искать флаг в ОЗУ, который указывает, что эскиз находится в ОЗУ

Ранее он рассматривал 0x20000C0 для этого шаблона (как показано в вашем коде), но когда мы выделяем все ОЗУ на эскиз, переменные эскиза будут помещены в расположение оперативной памяти, которое проверяет загрузчик

И проблема в том, что мы не контролируем то, что набросок будет положить в Offset 0xc00 из базы ОЗУ

На данный момент эскиз, по -видимому, последовательно помещает значение (из его VAR) в это место, которое загрузчик читает как действительный вектор SP

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

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

Я думал, что после загрузки в ОЗУ, загрузчик может просто переключиться на выполнение из ОЗУ, но, похоже, это не так. Кажется, он сбрасывает себя (не уверен, почему), а затем перезагружает Main () с самого начала.
Поэтому, если я не смогу заставить его работать без сброса, нам нужно сохранить гораздо более надежный флаг в коде, чтобы указать, что последняя загрузка была

Гарантированный способ сделать это состоит в том, чтобы не позволить эскизу использовать нижние 4 или 8 байт оперативной памяти и заставить загрузчик установить там магический номер, который, как мы знаем.

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

Я думаю, что люди, возможно, предпочли бы, чтобы мы просто избавимся от загрузки в Ram. Ну, я могу оставить это в коде, но, возможно, вернуть ошибку, E.фон. Загрузите в ОЗУ НЕТ

Роджер, я понимаю, что эскиз может загрузить все, что пожелает в ...C00, но, учитывая, что адрес 0x20005000 на самом деле не в диапазоне оперативной памяти для этого MCU, и, насколько я знаю, используется только для SP, каковы шансы, что эскиз будет использовать это 32 -битное значение где -то, а затем и затем шансы, которые будут хранить это точно на C00?

Оригинальный код маскирует все нижние биты, которые, я думаю, вызывает проблему, потому что любой адрес ОЗУ соответствует шаблону, когда вы маскируете все нижние биты адресов, и даже некоторые верхние... Поэтому, если наброски загрузили значение любого действительного адреса ОЗУ в эту позицию, проверка была бы положительной.

Но, проверяя 1 одно 32 -битный номер, который сверху является адресом в пределах диапазона, я не думаю, что мы должны получить ложные срабатывания.
Я собрал загрузчик, чтобы проверить его, но это было правильно, когда мой Mini умер и никогда не получил возможности проверить его. Теперь я думаю, что отремонтировал короткий в плате (Burnt 1117), и мой загрузчик работает, но я подозреваю, что более высокие адреса вспышки повреждены, потому что я обнаружил последовательный порт, но с неправильным идентификатором оборудования (0E0F, а не 1, так что водители не загрузить это. Я попробую протестировать всю свою вспышку позже со ST-Link с различными битовыми шаблонами, чтобы увидеть, не удастся ли какой-либо адрес, и если это так, чтобы сделать загрузчик для этой платы, которая загружает эскизы выше, чем это... Это займет меня занято, пока не появится другой Maple Mini

Виктор,

Использование вершины ОЗУ, кажется, стоит попробовать.

Возможно 64 -битный один.g unsigned long 0x1eaf1ab5

я.e в уважении к Leaflabs

PS Смотрите мои сообщения о том, что Stlink теперь работает намного лучше

Роджер,

Я считаю, что проверка на 2005000 год должна быть очень надежной, но если нет, то как насчет этого?
-Загрузка в ОЗУ установлена ​​верхняя часть ОЗУ 4 байта короче фактической ОЗУ, а адрес SP 1 байт ниже.
Мы храним 1 конкретное значение на этих байтах и ​​проверяем их.

Виктор,

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

Лично я бы бросил вариант загрузки на ОЗУ. В представлена ​​ненужная сложность, и я просто не вижу необходимости. Конечно, выбрал «быстрый и простой» метод.

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

Кстати, я использую emblocks для создания загрузчика и stlink jtag для отладки, что оказалось действительно полезным для отслеживания проблем, вызванных опцией загрузки на ОЗУ.

Боб

Я надеялся на 100% совместимость назад, но я согласен, вся загрузка на RAM является довольно бессмысленной

В качестве теста я запустил оригинальный Maple IDE и загрузил их набросок Blink в ОЗУ, и он работал ОК, но Blink берет около 90% доступной оперативной памяти

Таким образом, в реальном мире загрузка на RAM в основном бесполезен для любого эскиза, который действительно выполняет любую работу.

Я согласен, что это была жима.

Я посмотрю, смогу ли я заставить загрузчик вернуть сообщение об ошибке, если загрузка запрошен для Обратора. Я знаю, что это может вернуть коды ошибок, но я не уверен, что механизм прикрепления сообщения, так как код, кажется, никогда не возвращает сообщения об ошибках


Пса. Спасибо за совет об использовании EM: блоки для построения, поэтому я могу отлаживать через Stlink

Необычная идея.

У меня также есть Coocox, так что я мог бы также использовать это

Боб и Виктор

Переосмысливая это. ... Не обращайте внимания на мою публикацию ниже

Каким бы я ни делал, это будет немного взломать.

Я удалю опцию загрузки ОЗУ, возвращая ошибку, если выбран идентификатор ALT 0.
Я посмотрю, есть ли способ вернуть сообщение об ошибке по протоколу DFU

----------------- игнорировать остальную часть публикации ------------


Помимо того, что просто сбросить загрузку оперативной памяти, что все еще является лучшей идеей,

Я играл с идеей сделать это в качестве теста (см. Ниже)

Если я использую __attribute__ ((раздел (".noinit ")))))

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

Таким образом, глобальный беспигнутый длинный Ramuploadmagic; не будет инициализирован после теплой загрузки, следовательно, если я установите его на большой магический номер после завершения загрузки оперативной памяти, когда он снова загрузится, когда код считывает значение этого, он должен содержать тот же магический номер

я.e Это зависит от того факта, что компилятор кода поместит местоположение этой глобальной переменной в одном и том же месте в ОЗУ, когда -либо

Но я думаю, что это можно рассматривать как немного взлома

Другой вариант - просто использовать жесткий указатель на 8 байтов в верхней части ОЗУ

Я знаю, что в любом случае не является доказательством дурака, но единственный способ сделать это надежным образом - это сохранить значение во Flash / eeprom

Редактировать. КСТАТИ. Да. Я знаю, что загрузчик может вообще не работать с настройкой NOINIT, так как код может полагаться на настройку C arable на ноль, так что нужно сначала отсортировать, то есть убедитесь, что есть код для инициировать каждый вар. быть в начале. (Лично я всегда делаю это все равно)


#include "common.h" #include "dfu.h" extern volatile dfuUploadTypes_t userUploadType; __attribute__ ((section (".noinit"))) unsigned long ramUploadMagic; #define RAM_UPLOAD_MAGIC 0x1eaf1abs int main() { systemReset(); // peripherals but not PC setupCLK(); setupLED(); setupUSB(); setupBUTTON(); setupFLASH(); strobePin(LED_BANK, LED, STARTUP_BLINKS, BLINK_FAST); /* wait for host to upload program or halt bootloader */ bool no_user_jump = (!checkUserCode(USER_CODE_FLASH0X8005000) && !checkUserCode(USER_CODE_FLASH0X8002000)) || readPin(BUTTON_BANK,BUTTON); int delay_count = 0; while ((delay_count++ < BOOTLOADER_WAIT) || no_user_jump) { strobePin(LED_BANK, LED, 1, BLINK_SLOW); if (dfuUploadStarted()) { dfuFinishUpload(); // systemHardReset from DFU once done } } if (ramUploadMagic==RAM_UPLOAD_MAGIC) { // if we have just uploaded to RAM, then run whats in RAM jumpToUser(USER_CODE_RAM); } else

Роджер, помните, что в коде есть строка, которая идентифицирует каждый идентификатор?
Тот, который показывает что -то вроде "DFU Flash 0x8005000".
Что насчет того, чтобы изменить это для идентификатора ОЗУ, так что он показывает что -то вроде «загрузки в ОЗУ не поддерживается».
Поскольку эта строка возвращается загрузчиком при выборе опции, если вы можете вернуть ее перед кодом ошибки, любой, кто ищет, почему его загрузка на RAM не удалась, должен иметь возможность прочитать сообщение прямо здесь.
Это может быть вариантом вернуть сообщение.

Привет, Виктор,

Великие умы думают одинаково

КСТАТИ.

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

В нижней части USB_DICCICTION.C, я поместил небольшую утилиту JavaScript в качестве комментария.
Если вы скопируете комментированный код HTML JS во временный HTML -файл и откройте его в браузере
Он выплевывает код для массивов 3 идентификаторов Alt, поэтому сохраняйте необходимость делать их вручную.

Я также подумал, что делает маска в конфигурации. Он должен замаскировать 4 бита в регистре управления, когда загрузчик устанавливает режим контакта светодиода в качестве вывода и кнопки в качестве входного.

Поэтому, если у меня появится шанс, я добавлю код для моего клона Maple Rev3 и посмотрю, смогу ли я обновить этот загрузчик

Ребята

Я делаю еще немного работы над загрузчиком, чтобы добавить несколько комментариев кода в том, как портить на разные доски.
Но еще не все работает.

И у меня есть настройка 4 различных целей сборки, Maple Mini, Maple Rev 3, Maple Rev 5 (то же самое, что и Maple Rev 6 и Maple RET) и сборка для моего общего STM32F103C8, просто чтобы протестировать на другом светодиоде.

Я также написал простую утилиту HTML JavaScript для создания строк описания USB DFU DFU

GPIO в загрузчике должна быть настройкой формы первых принципалов, но я не думаю, что я все это понял, так как я не могу получить светодиод на PC13, чтобы Flash .


Я думал, что, как и номер версии, сообщения DFU, возможно, должны содержать, какую цель - сборка для E.глин. Поместите (Maple Mini) в конце текстов.

Виктор

Я не уверен, что идет не так, но я не могу изменить его, чтобы загрузчик был светодиод на порту C вместо порта B

Код конфигурации Maple Mini выглядит так
#define LED_BANK GPIOB #define LED 1 #define LED_BANK_CR GPIO_CRL(LED_BANK) #define LED_CR_MASK 0xFFFFFF0F #define LED_CR_MODE 0x00000010 #define RCC_APB2ENR_LED 0x00000008 /* enable Port B (bit 3 - see table above IOPBEN)*/ /* On the Mini, BUT is PB8 */ #define BUTTON_BANK GPIOB #define BUTTON 8 #define BUT_BANK_CR GPIO_CRH(BUTTON_BANK) #define BUT_CR_MASK 0xFFFFFFF0 #define BUT_CR_OUTPUT_IN 0x00000004 #define RCC_APB2ENR_BUT 0x00000008 /* enable Port B (bit 3 - see table above IOPBEN)*/

Роджер, вы проверили, как он сравнивается с загрузчиком Maple, который, по -видимому, имел светодиод в GPIOA:

Я посмотрел на код и, кажется, это только маски, которые меняются:
https: // github.com/leaflabs/maple-bootl ... аппаратное обеспечение.в

Также может помочь этот первоначальный коммит, адаптирующий загрузчик к доске под названием Robotis, так как светодиод был перенесен на другой PIN:
https: // github.com/gregwar/maple-bootlo ... BDDAF2B05F

Виктор

да. Я проверил на клене ret5 / 6, и то, что я изменил, казалось правильным

Я думаю, что у одного человека есть кленовый ret6, и он сам его построил, и он не просил новый загрузчик

Похоже, что Maple Rev3 может работать с загрузчиком Maple Mini, я думаю, что у него есть те же штифты для светодиодов и кнопки,
Я даже не думаю, что мне нужно изменить размер вспышки в загрузчике, так как Maple Rev 3 использует F103RB, который, кажется, такой же, как CB, просто в более крупном пакете

Всем привет,
Извините, у меня действительно нулевой вопрос.

Как мне сжечь 2.0 Bootloader на моем клоне Maple Mini?

Я где -то читал, что STM32Flash Утилита в инструментах может сжечь его, но я не могу найти .бин Файл 2.0 Bootloader.
Может ли кто -нибудь объяснить мне процесс сжигания загрузчика на Baite Maple Mini Clone?

Большое спасибо.

Если у вас уже есть Maple Mini с загрузчиком, просто загрузите эскиз, я разместил (см. Ссылку ниже) и следуйте инструкциям

ViewTopic.PHP?f = 21&t = 257&P = 3229&hilit = Updater#P3241

Tekk написал:<...>
Как мне сжечь 2.0 Bootloader на моем клоне Maple Mini?

Луча,

Он все равно должен работать, если они выберут старый загрузчик, они просто не получают выгоду, если они не выберут новый.

На самом деле на OSX и Linux мгновенная выгода гораздо более быстрая загрузка (хотя я не уверен, почему это так, так как это было то, что уже было рассмотрено в коде, который мы нашли, я.E Увеличенная версия оригинальной версии Leaflabs)

Rogerclark написал:Луча,

Он все равно должен работать, если они выберут старый загрузчик, они просто не получают выгоду, если они не выберут новый.

На самом деле на OSX и Linux мгновенная выгода гораздо более быстрая загрузка (хотя я не уверен, почему это так, так как это было то, что уже было рассмотрено в коде, который мы нашли, я.E Увеличенная версия оригинальной версии Leaflabs)

Mrburnette написал:Rogerclark написал: Честно говоря, я никогда не пробовал «нормальную» настройку на моем модифицированном министерстве... Я обновил загрузчик только для дополнительного SRAM.

@tekk

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

Новый режим (DFU ALT ID 2) загружается с начальным адресом 0x8002000
Где, как у старого загрузчика была только одна загрузка на местоположение Flash (DFU Alt Id 1) 0x8005000

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

Старый загрузчик имеет загрузку в ОЗУ (DFU ALT ID 0), однако это эффективно удаляется в новом загрузчике, потому что он практически бесполезен, так как большинство эскизов не вписываются в ОЗУ на 20K на Maple Mini - и были другие технические Причины того, что загрузчик определяет, имел ли он действительный набросок в ОЗУ после мягкого сброса, которые делают загрузку для RAM Проблемной.

(Опция загрузки на ОЗУ была удалена из меню загрузки некоторое время назад)

Но для совместимости DFU ALT ID 0 (загрузка RAM) сохраняется в новом загрузчике, он просто возвращает код ошибки, если вы попытаетесь его использовать (я.E путем модификации платформы.TXT или некоторые другие основные файлы)