Ребята

Я только что наткнулся на этот сайт, который утверждает, что имеет код на основе загрузчика Maple, который работает для F4

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

http: // www.Codeforge.com/article/304217


В любом случае, поскольку есть значительный интерес к F4, и ядро ​​@Danieleff Core и Core STM, но загрузка через встроенный загрузчик является проблематичной, я думаю, если бы мы могли получить код загрузчика F4, это было бы удобно.

При этом я не уверен, что между кодом загрузчика F1 и F4 будет большая разница. Основными различиями будет настройка MCU, включая PLL, а также адреса регистра всех оборудования.
Могут быть и другие различия между контролем USB низкого уровня на F1 и F4, но, возможно, не так много.

В то же время, но это только для платы F4 Black Vet6, на самой плате есть 4 кнопки ', * Sketch * может использовать эти кнопки для другой цели.

Затем некоторые ссылки:
Справочное руководство STM32 F4 RM0009
http: // www.ул.com/content/ccc/resource/ ... 031020.PDF
Виктор - тот, кто указал на это в ветке #include #define LED_PIN1 PA6 //PB9 // #define LED_PIN2 PA7 uint16_t counter; SPIClass spi(1); #define SS_PIN PA4 // the setup function runs once when you press reset or power the board void setup() { pinMode(LED_PIN1, OUTPUT); pinMode(LED_PIN2, OUTPUT); pinMode(SS_PIN, OUTPUT); Serial.begin(115200); counter = 0; spi.beginTransaction(SPISettings(1312500)); } // the loop function runs over and over again forever void loop() { Serial.println(counter++); digitalWrite(LED_PIN1, LOW); digitalWrite(LED_PIN2, HIGH); delay(500); // wait for a second digitalWrite(LED_PIN1, HIGH); digitalWrite(LED_PIN2, LOW); delay(500); // wait for a second digitalWrite(SS_PIN, LOW); spi.transfer(0x55); digitalWrite(SS_PIN, HIGH); }

@AG123

В окнах у меня много проблем со встроенным DFU, что действительно делает его непригодным для меня

Я думаю, что ST использует там собственную / специальную версию DFU-UTIL, которая имеет расширения, которые они используют, но не в версии DFU, которую мы имеем для Windows.

Кроме того, я читал, что у людей, кажется, возникают проблемы с загрузкой драйвера, и ему нужно использовать Zadiag (хотя у меня не было этой проблемы)

Единственный способ загрузить через DFU, - это использовать собственную программу загрузки STM, которая требовала, чтобы файл был в специальном формате (Arrggghhh)

Итак, я отказался от этого.

Re: сброс USB, код эскиза может сделать это так, как это происходит на F1, изменив PIN -код USB D+ (я забыл, если он PA13 или PA14) на GPIO и запустив его на короткое время, прежде чем изменить его обратно на Операция по плаванию / USB.


Однако в целом, я думаю, что нам было бы лучше с F4 версией Maple Bootloader.

Rogerclark написал:Ребята

Я только что наткнулся на этот сайт, который утверждает, что имеет код на основе загрузчика Maple, который работает для F4

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

http: // www.Codeforge.com/article/304217


В любом случае, поскольку есть значительный интерес к F4, и ядро ​​@Danieleff Core и Core STM, но загрузка через встроенный загрузчик является проблематичной, я думаю, если бы мы могли получить код загрузчика F4, это было бы удобно.

При этом я не уверен, что между кодом загрузчика F1 и F4 будет большая разница. Основными различиями будет настройка MCU, включая PLL, а также адреса регистра всех оборудования.
Могут быть и другие различия между контролем USB низкого уровня на F1 и F4, но, возможно, не так много.

Я использую dfu-util из Sourceforge (v 0.9, но я бы подумал, что нижние версии тоже работают)
http: // dfu-util.Sourceforge.net/dfuse.HTML
Он работает с DFU ST на F4, я прошиваю / тестировал различные эскизы / ядер F4 таким образом довольно недавно

К сожалению, так как это я работаю в Linux. Мне нужно настроить стек USB, чтобы проверить его в Windows 7, если мне нужно проверить это.

@AG123

Я попробовал это один раз в Windows без успеха. Но я попробую еще раз.

Казалось, DFU в Windows несколько более хлопотно из -за необходимых различных зависимых компонентов. Соответственно, есть «стек драйверов», необходимый в дополнение к дополнительным конфигурациям отчасти потому, что DFU-UTIL использует Libusb, который, в свою очередь, использует Winusb. Этот стек драйверов, по -видимому, винсб <- Либусб <- dfu-util

Некоторые из найденных ссылок следующие:
https: // github.com/libusb/libusb/wiki/windows
http: // zadig.Акео.т.е./
https: // msdn.Microsoft.com/en-us/librar ... 40196.aspx
https: // msdn.Microsoft.com/en-us/librar ... 40174.aspx
http: // dfu-util.Sourceforge.сеть/

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

Очевидно, этот пост от Pito показывает некоторые подсказки, казалось, что либусбк (который представляет собой внедрение с открытым источником Winusb) необходимо установить (e.глин. через Zadig) для использования dfu-util v0.9
http: // www.STM32duino.com/viewtopic.PHP ... 188#P26207

на черной плате STM32F407VET6
http: // wiki.STM32duino.com/index.PHP?title = STM32F407
обнаружено, что загрузчик DFU ST не выполняет USB-резит, даже если установлен перемычка Boot0, а сброс нажат.
Следовательно, комментарий Пито о том, что необходимо отключить USB -кабель и заменить его после установки перемычки Boot0
Я не слишком уверен насчет других досок, хотя

Я отметил, что такие доски, как STM32F4 Discovery
http: // www.ул.com/en/evaluation-tools/s ... овсяной.HTML
Я не уверен, что это, вероятно, означает, что USB-порт по умолчанию можно использовать только для ST-Link, а не USB
Но, согласно ветке, обсуждающей черную плату STM32F407VET, ST-Link, кажется, является более эффективным способом установления эскизов, так как она не нуждается порт на доске
http: // www.STM32duino.com/viewtopic.PHP ... 188#P26207

Надеюсь, это поможет

@AG123

ммм. Я могу попробовать на другой машине Windows, но я не заинтересован в том, чтобы испортить свои существующие драйверы, используя Zadiag и т. Д

Следовательно, причина, по которой я искал лучшее общее решение для пользователей Windows, имея версию F4 Bootloader F103

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

В предыдущей ветке, обсуждающей черную доску STM32F407VET6
http: // www.STM32duino.com/viewtopic.PHP ... 188#P26207

Преобладающие мысли, по-видимому, заключаются в том, что ST-Link, возможно, более практичен и удобен для установки эскиза и т. Д. Вместите вмешательство с булавками и т. Д., И что (отсутствие) сброса USB оказалось неприятным

Тем не менее, мы обязательно получим «пользователей», которые просто получают эту доску, но у меня нет ST-Link. Следовательно, мысли заключаются в том, что если эти «пользователи» готовы обойтись с DFU, несмотря на неудобства, которые они могли бы вмешиваться с помощью бутинок, отключать и т. Д

Что касается меня, я «обошел» (отсутствие) USB-резит, используя утилиту в Linux, которая делает это USB-резит. Следовательно, это спасает меня немного неприятностей, кроме вмешательства с булавками, мне не нужно буквально отключать / заменить USB -кабель
--
Тем не менее, загрузчик - это хорошая идея, так как это спасет все проблемы с вмешательством с помощью бутинок, и мы можем выпустить USB -сброс, если нам нужно

Я думал, что все еще должно быть возможно загружать загрузчик на F4 через USB в сериал, как F1.

Re: возиться с ботинками.

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

https: // Stackoverflow.COM/Вопросы/282 ... 2#28288454

Но я все еще думаю, что все, что касается Zadiag, даже на W10 оттолкнет много людей.

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

Rogerclark написал:Следовательно, если бы у нас был загрузчик, как на F1, это было бы намного меньше хлопот для всех

Я провел некоторое исследование по этому поводу сегодня и попытался зарегистрироваться (используя временный адрес электронной почты) на сайте, на котором был загрузчик F4 Libmaple, но сайт, кажется, сломан, поэтому я не думаю, что есть много надежды на это код.

Я также нашел загрузчику для платы контроллера полета PX4, которая использует STM32F4 и удалось его построить и загрузить на мою черную плату F4, но это не перечислялось на USB.

https: // github.com/px4/bootloader

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

Я думаю, что код PX4 можно запустить на F4 Discovery, но я не пробовал это

https: // pixhawk.Org/Modules/STM32F4Discovery

Кроме того, я не уверен, что на самом деле делает загрузчик

Редактировать.

Я только что нашел схему для PX4 https: // raw.githubusercontent.com/px4/h ... v2.4.5.PDF

И похоже, что разъем USB находится на булавках OTG (ну, это то, что они помечены)

Что объясняет, почему загрузчик не работал с платой Black F4, так как я думаю, что USB -разъем находится на первичных контактах USB, а не OTG

Эти булавки, помеченные как OTG_FS_DP/DM, являются «нормальными» USB -контактами на PA11/12, аналогично Black F4.

Посмотрел коды загрузчика PX4 на GitHub, казалось, что у меня сложилось впечатление, что это загрузчик UART, но я не уверен, хотя
Нет, неверно, он, кажется, использует последовательный протокол для загрузки / вспышки изображения
https: // github.com/px4/bootloader/blob/master/bl.C#L524
и казалось, что USB-сериал CDC-ACM поддерживается

Нашел здесь что -то интересное, я не пробовал это, прыгая на внутренний загрузчик DFU STM32F4
https: // github.com/microReady/stm32f4_dfu_demo

Я думаю, что где-то здесь есть ветка, в которой я не мог найти, в котором упомянул Виктор, что можно установить «программные булавки»
я.эн. Мы можем установить Boot0 с помощью некоторых регистров и сделать сброс, затем он упадет в режим DFU
Это вполне может быть коротким сокращением, чтобы сделать загрузчик DFU-Boot, но вам нужно будет решить проблему ST DFU'SE на вашем рабочем столе
И, кроме того, нам все еще нужно решить проблему «без USB -сброса» с загрузчиком DFU от STM DFU

RM0009 F4 Справочное руководство
http: // www.ул.com/resource/en/reference ... 031020.PDF Page 291 9.2 Регистры SYSCFG для STM32F405XX/07XX и STM32F415XX/17XX
9.2.1 SYSCFG Memory Register (SYSCFG_MEMRMP)
Этот регистр используется для конкретных конфигураций при переоценке памяти:
• Два бита используются для настройки типа памяти, доступной по адресу 0x0000 0000.
Эти биты используются для выбора физического переработка программным обеспечением и поэтому обходят загрузку
штифт.
• После сброса эти биты принимают значение, выбранное штифтами загрузки. При загрузке из
Основная флэш -память с бухгалтами, установленными на 10 [(boot1, boot0) = (1,0)] Этот регистр
берет значение 0x00. И этот дизайн, вероятно, будет означать, что нам либо нужно ждать кнопки нажатия на доску
Или на рабочем столе необходима утилита, чтобы отправить команду, скажем, USB-сериал во время перезагрузки, что запустило бы режим DFU
Это было бы сложно, потому что в тесной координации потребуются 2 отдельные утилиты
Утилита для отправки команды USB-серии и DFU-UTIL для загрузки эскиза после сброса
----------
Другим способом, однако, мы используем кнопку «дополнительная» на плате в кодах ядра Libmaple, чтобы, если нажата эта кнопка, она сбрасывалась и переходила в DFU-режим. Скорее всего, определение дополнительного компиляции
---
2 добавления из Google Search
https: // github.com/hooao/stbooter
^^ это, кажется, выполняет загрузку с использованием некоторого протокола YModem, на основе UART на основе
https: // github.com/rdmaxes/stm32f4_seri ... загрузчик
^^ Это похоже на загрузку с использованием некоторого протокола YModem, на основе UART на основе

@AG123

Спасибо, что посмотрели на этот загрузчик.

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

Загрузка через USB -серийный, а не DFU не обязательно является проблемой, в зависимости от того, что такое протокол. Я помню, как @JWC написал загрузчик для F1, который использовал тот же серийный протокол, который встроен в Arduino IDE.

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

Re: загрузка в встроенный загрузчик DFU.

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

Поэтому я все еще предпочитаю вариант нашего собственного загрузчика.

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

РЕДАКТИРОВАТЬ
- В критическом моменте здесь заключается в том, что, согласно моему опыту на сериале F4 USB, текущая реализация, по -видимому, теряет иногда некоторые байты и/или висит, если много данных передается. У нас была аналогичная проблема на F1, но поскольку здесь код отличается, нам нужно отдельно исследовать проблему.
- Другой момент заключается в том, что приложение Flasher должен Беги из барана, иначе это может удалить себя на лету. Я думаю, Рик (или это было пито?) имеет решение, как позволить приложениям работать от оперативной памяти, так что это знает, как можно использовать здесь.
- Кроме того, или альтернативно, мы могли бы использовать двухэтапный флешер: первая сценическая загрузка загружает приложение Flasher (второй этап) через USB Serial To RAM, а затем позвольте второму приложению Flasher запустить из ОЗУ. Это получит новый код через USB -сериал. Погрузчик первого этапа может быть очень тонким, чтобы во время обычного пробега не было много ресурсов. Конечно, первая и вторая карта загрузчика оперативной памяти должна быть определена, чтобы избежать перекрытия друг друга.

Есть еще один сценарий, в котором мигалка мог жить по какому-то адресу «высокой памяти», так что, когда «магическая последовательность» получена на серийном USB, мы можем прыгнуть к мигнуту. Но у этого все еще есть улов в том, что USB -сериал, возможно, всегда должен быть инициализирован как отключение USB_SERIAL, возможно, означает отключение доступа к мигающим.

AG123 написал:Есть еще один сценарий, в котором мигалка мог жить по какому-то адресу «высокой памяти», так что, когда «магическая последовательность» получена на серийном USB, мы можем прыгнуть к мигнуту. Но у этого все еще есть улов в том, что USB -сериал, возможно, всегда должен быть инициализирован как отключение USB_SERIAL, возможно, означает отключение доступа к мигающим.

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

Я думаю с точки зрения «портирования» существующего загрузчика STM32Duino загрузчика в F4. В этом смысле было бы гораздо проще интегрировать в ядро. Нам не нужно будет иметь другое приложение на стороне хоста, чтобы выполнить установку эскиза, так как нам нужно подумать о нескольких платформах Windows, MacOS, Linux.

Я думаю, что в настоящее время есть утилита, которая выполняет эту специальную последовательность сброса USB-сериала:
http: // docs.Leaflabs.com/static.Leaflab ... 3-rev5-dfu SetupClock120MHz();

Ага. Не спешите.

Жаль, что в F4 был рабочий порт загрузчика F1, но у нас нет возможности добраться до кода, поскольку на сайте несуществующего китайского языка.

Я предполагаю, что я мог бы попробовать PM «2 или 3 китайских пользователя на форуме и посмотреть, смогут ли они исследовать, так как они могут выяснить, доступен ли код в других местах китайцев

казалось, что @jcw уронил здесь совет
http: // www.STM32duino.com/viewtopic.PHP ... = 70#p28847
https: // github.com/jeelabs/emello/ree ... S/USBSerup
У него есть загрузочный загрузочный загрузчик USB, который использует серийный протокол загрузки STM, который установлен в «High Mem»

Я думаю, что это довольно целесообразно адаптироваться к F4 E.глин. Вместо DFU мы могли бы использовать серийный. Но, тем не менее, как и в любом проекте S/W, это займет некоторое время & усилия порта, даже если это кажется поверхностно «легким». Во -первых, USB -оборудование на F4 все еще отличается от F1. Нам нужно было начать с другого USB -аппаратного «драйвера» для начала с.

Учитывая сравнения, мы могли бы также пойти медленно и вместо этого сделать загрузчик Maple DFU. В этом смысле это было бы расширение текущего загрузчика DFU в стиле кленового стиля, который работает аналогично как для F1, так и для F4. И одна из вопросов, которые он сдает в виду, - это стек и утилиты для драйверов и утилиты для хоста, которые могут иметь свои собственные проблемы с хостом. Следовательно, начиная с довольно зрелых инструментов на стороне хоста может спасти некоторые проблемы с интеграцией в ядро

Спасибо

Я знал, что @jcw сделал высокопоставленный загрузчик памяти. Возможно, он даже начал его как загрузчик с низким содержанием памяти (возможно, стоит взглянуть в истории коммита)

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

Я хотя, что он использовал тот же протокол загрузки, что и платы AVR (я забыл, что называется), но, возможно, он изменился на использование формата серийного загрузчика STMS (или никогда не работал протокол загрузки AVR)
Нам нужно спросить его

Разве пользователю не было бы проще иметь перетаскивание массового хранения&уронить .мусорная корзина в стиле USB -диска Flasher? (как mbed). Не нужно устанавливать драйверы USB.

Да. Это было бы хорошо, хотя я подозреваю, что люди должны будут рано или поздно установить серийные драйверы, E.глин. Использование собственных драйверов STM или использование взлома, который мы используем для Libmaple

Но я согласен, USB Mass Storage стоит изучить, особенно если оно может иметь уникальное имя, чтобы загрузка мог перечислить диски и найти его без необходимости выбрать его (как мы делали с загрузкой ядрево. )

Но USB MSC (Mass Storage) также является частью приложения пользователя, верно? В этом случае у нас снова возникает проблема с загрузкой, когда приложение пользователя висит.
В любом случае, я бы тоже приветствовал MSC в качестве опции загрузчика.
Тем не менее, DFU кажется мне самым быстрым внедренным вариантом на данный момент, с меньшими усилиями, чем в сочетании с MSC.

Установщик «класса массового хранения» привлекательна, просто ощущение, что он был бы несколько более крупным. Кроме того & более спроектирован для цели. Я думаю о том, чтобы пойти с DFU в основном с DFU в стиле Maple, так как это, вероятно, облегчит интеграцию с существующим ядром, используя те же инструменты и сценарии

По теме загрузчика массового хранения.

Сегодня я наткнулся на это видео (на русском языке), отвечая на вопрос от кого -то на YouTube

https: // www.YouTube.com/watch?V = Q1R8YXKNQH4

Он ссылается на эту страницу (на русском языке) http: // www.Авислаб.com/blog/stm32-bootloader_ru/

Что ссылается на этот код в GitHub https: // github.com/avislab/stm32f103/tr ... Загрузчик

Код, кажется, содержит двоичный файл для F103, но у меня еще не было времени попробовать его

Я пробовал это, но бинар в GitHub не подходит для USB для меня.

Редактировать.

PB1 необходимо потянуть низко, в противном случае он, похоже, не запускает свое USB -массовое хранилище

Я предполагаю, что PB1 высок, он прыгает до 0x8003000, но мне нужно дважды проверить.

Другая вещь, которую я заметил, заключается в том, что я не думаю, что код поддерживает FAT -файловую систему, поскольку автор использовал программу Disk Imager Win32 для написания необработанных данных на устройство.

На теме загрузчиков массового хранения было бы здорово сделать тот, который поддерживает новый формат UF2.
UF2, по сути, берет концепцию, стоящие за шестнадцатеричными файлами, в которых у вас есть записи адреса+данные, только он разграничивает их границами 512-байтовых секторов вместо разрывов строки, так что каждая запись гарантированно написана атомной.

По сравнению с большинством Demo Mass Hoolguster-загрузчиков, загрузчик массового хранения UF2 должен работать над всеми основными OSES.

Вот пост в блоге, в котором подробно рассказывается:
https: // makecode.com/blog/chip-to-flash-them-all

Очевидно, их (атмолетная) версия SAMD загрузчика UF2 подходит в 8KIB, что довольно впечатляет, так как я едва могу подгонять обычный загрузчик DFU в 8KIB.

Эта версия USB Mass Storage, кажется, занимает около 9.5K, хотя я думаю, что это, возможно, не оптимизировано, как это в папке под названием Debug E.глин. это, вероятно, будет сборкой отладки

Проблема с протоколом массового хранения USB заключается в том, что в обычном смысле устройство просто представлено как *блочное устройство *.
(FAT) файловая система полностью обрабатывается хостом O/S, который может включать в себя обновление записей каталогов, кластерных карт и битовых карт. Хост может буквально попытаться «написать где угодно» на устройстве, он может выбрать написать дополнительные файлы, метадаты (e.глин. записи VFAT) и т. Д
Это не только усложнит задачу написания установщика Flash, и это, вероятно, внесло бы ошибки / несовместимость на разных платформах, E.глин. Хост может быть ПК с Windows (есть много версий Windows), macOS (опять же, много разных версий ОС), ПК Linux (опять же, много разных версий ядра) и телефон Android, а также iPhone и т. Д. Все они могут обрабатывать жировые файловые системы несколько по -другому.
Следовательно, USB -массовое хранилище для обновления прошивки не совсем «без водителя», это, вероятно, «запрограммирован для интерпретации конкретного протокола ОС -ОС хоста для обработки жирных файловых систем», это основное место для обновлений прошивки, оно может работать на одной платформе и сломать другой, скажем, он работает на Linux, и ломается на Windows и т. Д.

Следовательно, протокол «разработан для цели» более подходит для этой цели, DFU является одним из них. Мы также могли бы реализовать протокол серийного загрузчика ST
Но, учитывая DFU - это «довольно стандартный» протокол, было бы неплохо продолжать использовать его, поскольку он использовался с исходным кленом (MINI)
В настоящее время утилита Utility DFU-UTIL с открытым исходным
http: // dfu-util.Sourceforge.сеть/
Это в значительной степени «адекватно» как «драйвер» на стороне хоста. Насколько вы знаете, учитывая растущую распространенность этих устройств, «стандартные» драйверы DFU могут проникнуть в Windows, Mac, Linux и другие платформы
Не так уж и сложно предвидеть, что «прошивая программируемая» периферийные устройства USB, E.глин. Мышь, клавиатуры, любые USB -гаджеты и т. Д. Могут стать общими технологиями и что DFU или, возможно, DFU с некоторыми улучшениями E.глин. Dfuse становятся общим протоколом для всего, что

На самом деле есть еще один USB -протокол Fastboot от Google Android, но кажется, что Fastboot может быть довольно громоздким для реализации на низкой вспышке, Memory MCU
https: // android.Googlesource.com/platfo ... /fastboot/

всего 2 цента

У меня была еще одна мысль о том, где мы можем получить загрузчик F4 DFU, и кажется, что у Blackmagic Grye была F4 -версия их загрузчика DFU, но он был удален в этом коммите

https: // github.com/blacksphere/blackmag ... C9FC53F5D6

Если я получу время, я попробую проверить предыдущий коммит и посмотрю, компилируется ли он для grov_host = f4discovery, поскольку эта цель должна строить, поскольку F4 является устройством BMP

Примечание. Я пытался создать последнюю версию для F4Discovery, так как это должно обеспечить ядро ​​функциональности BMP (но не DFU)
Однако USB, похоже, вообще не сработала для меня, когда я это сделал.
Я попробовал и My Discovery F4, а также общая доска F407, но ни один из них не перечислен на USB
Так что я не понимаю, почему это не работает сейчас, потому что ребята из чата BMP Gitter думали, что это должно работать.

Роджер, ты пробовал необработанный бинар на диско? http: // builds.Черное место.сопутствующий.NZ/Blackmagic/

Означает ли это, что мы могли бы превратить черную плату F4 в зонд BMP? Звучит интересно.

Да. Он должен превратить доску F4 в BMP. (По словам ребят на gitter) я посмотрел на Makefile, и он построен для Cortex M4, так что, похоже, он должен нацелиться на F4

Но я попытался построить свой бинар, но, похоже, не работал ни на моей доске, так и на моей доске F4 Discovery, ни на моем доске F407



Я постараюсь пропустить предварительно построенный бинар на моем Discovery F4