Роджер, я модифицировал Chriss Bootloader для работы над F407, перечислял сброс, как мы обычно делаем, и в настоящее время ждать десять секунд, если есть эскиз на вспышке, и на неопределенный срок, если в базовом адресе ничего не напоминает вершину вершины Указатель стека.
Эскизы должны быть скомпилированы для 0x08004000
Я прикрепляю файл корзины для 407.
Он должен работать со стеком в обычной оперативной памяти или CCMRAM.
Я протестировал загрузчик с отладчиком, я еще не сделал, это загрузка эскиза, используя его, потому что я не знаю, какой инструмент можно использовать. Доска обнаруживается как устройство STM DFU.
Я никогда не использовал загрузки STM DFU, мне потребовалось некоторое время, чтобы даже найти драйвер, который мне пришлось загрузить в Windows, но инструмент DFUSE не принимает обычные файлы бина.
Bootloader в настоящее время занимает менее 13 КБ, но, поскольку первая страница составляет 16 КБ, вся страница зарезервирована, а Sketch Can загружается, начиная на второй странице (0x08004000)

F4bootloader.молния

(9.7 киб) скачано 29 раз

Спасибо, Виктор

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

Он построил сразу же для вас, или вам нужно было что -то изменить в файлах True Studio Project.

Re; Загрузка в формате dfuse
Ах, это может быть проблематично.

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

Вы пробовали использовать Zadig для замены драйвера STS на драйвер WinusB, а затем использовать 64-битный DFU-uth (для Windows), которая находится в папке инструментов моего репо?

Мне удалось загрузить в встроенный загрузчик, выполнив эти два шага.
Поскольку новая версия DFU-UTIL, похоже, не работает с Linusb-Win32, с которой Maple DFU совместим с.

Я пытался загрузить драйвер WinusB для PID Maple VID, но, похоже, не работает

PS вы можете использовать Wei-Simple.exe для установки Winusb, вы просто используете "type = 0" вместо "type = 1"

Но убедитесь, что вы сначала удалили драйвер, прежде чем обновить устройство для Winusb, так как я не уверен, что Вэй-Симпл или Задиг Удалите существующие драйверы

КСТАТИ.

Я также настроил цепочку инструментов и т. Д. На виртуальной машине Linux для создания загрузчика @Devan, сделал тестовую сборку для F1 и начал вносить изменения, необходимые для F4, но код резервного копирования не был совместим с F4 и I. Думаю, я получил множество других ошибок компиляции, когда я пытался построить для F4, поэтому мне пришлось припарковать код, так как у меня не было времени, чтобы выяснить, что случилось.

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

Я пытался построить с помощью Eclipse, не сработал, загрузил новое затмение, не сработал, и через некоторое время потратив свое время, я решил, что было проще загружать Systemworkbench, вот для чего проект был создан изначально, и это сработало отлично.
Затем я сделал несколько изменений для F407, так как есть несколько различий, но я, вероятно, потратил 1/10 случаев, делая эти изменения, по сравнению с тем, что я потратил, пытая...

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

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

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

Re: Eclipse

У меня были такие же проблемы с True Studio.

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

Я тоже скачиваю Systemworkbench

Спасибо

Роджер

Установил загрузчик, и я вижу его на USB

И у меня уже установлен драйвер Winusb для этого VID/PID

Так что теперь мне нужно изменить код Libmaple F4 для создания с этим смещением

Виктор, так как этот поток больше не о внутреннем загрузчике, я разделил его

К вашему сведению

В настоящее время я изменяю Libmaple F4, чтобы справиться с другим векторным смещением, передаваемым из досок.текст

Я написал весь код, но я все еще тестирую его сейчас (я.e Это не работает !)

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

ХОРОШО

У меня есть смещение векторного стола, работающее с Libmaple F4

Я добавил меню загрузчика в Generic, в настоящее время он по -прежнему говорит «STM32Duino Bootloader», но это потому, что у меня не было времени, чтобы изменить его

Это немного взломать, так как по какой -то причине мне пришлось определить векторные вещи для всех досок, даже если в Libmaple есть добавленная Ifndef.H, где он определял значение user_addr_rom, которое используется в платах.CPP

Загрузчик, кажется, содержит около 15 секунд, затем прыгает в код и мигает мой светодиод

Теперь мне нужно работать над загрузкой через DFU

Пса. Да. Я добавил новый файл линкера

Смотрите прикреплено

Пса. Я надеюсь, что Zip содержит все изменения

Примечание. Я только добавил файл для общего F4, так как в настоящее время использую плату "Blue F4" для тестирования

Ппс.

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

Возможно, мы сможем сделать это в загрузчике, так как мой компьютер навсегда показывает устройство USB DFU, когда мой эскиз Blink работает

Отлично, я тоже получил свою первую компиляцию, но все равно должен изменить драйвер и попробовать Dfuutil, просто изменил это в досках.CPP, и добавил это определить в .строить.век для доски: /* default is double precision, define this for single precision */ #undef SINGLE_PRECISION

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

Файлы, которые я разместил, работали для меня, но только когда я загружен через STLINK на 0x8004000

На данный момент я вообще не могу заставить DFU-UTIL работать вообще, он просто продолжает время и прыгает на приложение

Виктор

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

Последняя страница на 0x08009233 не подлежит написанию
/* default is double precision, define this for single precision */ #undef SINGLE_PRECISION

Виктор

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

Так что, кажется, определенно возникают проблемы с кодом загрузчика Криса.

Я даже попытался установить адрес 8000000, если у вас жестко закодировал начальный адрес и т. Д

эн.глин.
Starting test Beginning Whetstone benchmark at 168 MHz ... Loops:2000, Iterations:1, Duration:3946.32 millisec C Converted Single Precision Whetstones:50.68 mflops

Я получаю аналогичную ошибку при попытке загрузить, а затем читаю вспышку назад, я вижу, что ничего не было загружено, но некоторые страницы были заполнены 0s.
Мне придется больше копаться в загрузчике, чтобы увидеть, что происходит.
Кстати, я попробовал с драйвером Libusbk, что Zadig может установить с тем же результатом.
Я думаю, что у меня есть представление о проблеме. Я получаю это, когда использую опцию -v с dfuutil: DFU MODE DEVICE DFU Версия 011A
Устройство возвращалось размер передачи 1024
Имя интерфейса DFUSE: «Внутренняя вспышка»
Сегмент памяти по адресу 0x08000000 4 x 16384 = 65536 (r)
Сегмент памяти по адресу 0x08010000 1 x 65536 = 65536 (rew)
Сегмент памяти по адресу 0x08020000 3 x 131072 = 393216 (Rew)
Загрузка в адрес = 0x08004000, размер = 24140
Последняя страница на 0x08009e4b не подлежит написанию Как вы видите, все 4 из первых 16 -килограммовых страниц помечены как (r), а не то, что другие были RW. Первоначально Крисс зарезервировал 4 страницы для своего загрузчика, 64 КБ, но я изменил это на 16 КБ. Я, должно быть, оставил его без изменений в каком -то месте. Я вернусь к коду и проверю его.

Кстати, если я настрою адрес загрузки на 0x08010000 в dfuutil, он загружается без какой -либо ошибки.

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

ХОРОШО

Я видел, что @pito использовал драйвер Libusbk, но Winusb отлично работает для меня, используя встроенный загрузчик, поэтому я не пробовал версию Libusbk, поскольку она казалась неактуальной

Виктор

ХОРОШО.

Я собирался предложить изменить вектор смещения на 0x8010000

Но ваш код не подпрыгнет по этому адресу, поэтому даже если он загружен ОК, он не будет работать

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

Ну, это исправлено сейчас, все, что осталось, - это перечисление.
Я заменил вложение в первом сообщении на один, который правильно загружается по правильному адресу (0x8004000) и запускаю код оттуда.
У него все еще длинный тайм -аут, который можно изменить позже для окончательной версии. Просто нужно исправить проблему с не повторным выражением. Я думал, что это сделает это, так как код уже был там от Крисса, но, возможно, нужно больше времени.

Спасибо

Я скачаю снова и проверю

Ммм

Я получаю ту же ошибку

Можете ли вы репостировать файл ZIP под другим именем, возможно, есть проблема с кешами файла

Виктор.

Моя ошибка

Я прошил старую версию.

Одну вещь, однако... Он не прыгает на код эскиза, когда DFU закончен.

Есть ли способ, которым мы можем заставить это сделать это ?

Я попробовал вариант -r для сброса, но это не помогло

Виктор

К вашему сведению.

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

F1 имеет «rxhook», который настроен так, чтобы функция rxhook () в USB_SERIAL.C называется каждый раз, когда что -то прибывает через CDCACM
Но у F4 этого нет, и файлы CDCACM выглядят сильно отличающимися от версий F1.

Так что я еще не внедрил эту функциональность.

Я постарался посмотреть, будет ли код сброса из F1 работать с F1, но опять же, код, лежащий в основе F4, не имеет функции сброса NVIC и т. Д.
Я попытался взять код ассемблера из F1 и части F1 NVIC Code E.глин. от SCB.H и т. Д., И поместите его в эскиз, но, насколько я могу судить, код F1 не работает правильно на F4.

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

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

В любом случае, если это вам при пользу, вот моя попытка наброски, которая сбросила бы MCU

(На моем доске. PB0 - это светодиод, поэтому код мигает светодиод 10 раз, затем вызовет Reset_to_bootloader

reset_to_bootloader () приводит к Low Drive PA12 (USB DP), а затем устанавливает его обратно на плавание, в надежде, что когда плата сбросится, USB -хост ПК, замечает, что устройство STM DFU теперь появилось.


Loops: 1000Iterations: 10Duration: 9984 millisec. 1677419955 clocks C Converted Single Precision Whetstones: 100.16 MIPS

Я загрузил здесь свою вилку:
https: // github.com/Victorpv/f4bootloader

Это тот, который генерирует корзину, прикрепленную в первом посте.
Я собрал его, используя новейшие Systemworkbench, доступный от OpenStm32.орг

Светодиодные и кнопки определены в /inc /main.час

У меня, вероятно, больше не будет времени на работу над этим сегодня. Если я достигнуте какого -либо прогресса, я обновлю его.

Спасибо

Я скачаю систему Workbench и посмотрю, смогу ли я его построить

КСТАТИ.

Новый DFU-UTIL, который работает с этим загрузчиком, кажется, не работает правильно с загрузчиком Maple Bootloader.
Получает ошибку в конце.

Поэтому, пока у меня не будет времени исправить загрузчик Maple, мы не можем просто переключиться на новую DFU-UTIL как для F4, так и для F1

Я думаю, что я также посмотрю на ядра STM32Generic и STMS F4, потому что Libmaple F4 отсутствует во многих функциях, и у меня нет времени, чтобы обновить его

Виктор

Какую версию GCC вы используете для компиляции загрузчика?

Я получаю ошибки во многих файлах e.глин. основной.C GPIO.C и некоторые из файлов HAL.

Помимо Arduino, я использую GCC 5.4, (как мне нужно это для других MCU), но я попробую настроить, чтобы он использовал тот же компилятор, что и Arduino IDE, (который, я думаю, V 4.8)

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

Я удалил GCC 5.4 с моего основного пути, и теперь он собирает ОК

Виктор

У меня, вероятно, не будет времени, чтобы попробовать это до сегодняшнего дня, но глядя на код, который у него есть
Loops: 1000Iterations: 10Duration: 9985 millisec. 1677420928 clocks C Converted Single Precision Whetstones: 100.15 MIPS

Виктор

К вашему сведению.

Я перечислил его, чтобы прошить светодиод, который находится на моей доске (PB0), и в конечном итоге заставил его работать, но какое -то время он не будет мигать, потому что Portb вообще не был инициирован.

Код, вероятно, должен инициировать все порты или иметь #ifdef, чтобы убедиться, что кнопка и светодиодный порт полностью инициированы, а не только булавки

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

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

Я также рассматривал интеграцию с STM32GENERIERIER, так как у него уже есть код для перезагрузки F1 на основе волшебной последовательности через USB -сериал.
Проблема, однако, в Maple_Loader.JAR не предназначен для работы с новой версией DFU -UTIL, которая нуждается в аргументе -S.
(Ну, я не уверен, есть ли это или нет, как некоторые комментарии, команды Metion для dfuse, но это не ясно, это -с или что -то еще

В любом случае, загрузчик Maple Bootloader и этот загрузчик F4 не могут оба использовать более новый DFU-UTIL, который поддерживает DFUSE, поэтому нам понадобится отдельный файл / сценарий летучих мышей для F4_LOALER, который вызывает новую подкладку DFU-UTIL.

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

эн.глин.
Loops: 1000Iterations: 10Duration: 6988 millisec. 1677248483 clocks C Converted Single Precision Whetstones: 143.10 MIPS

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

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

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

Еще одна вещь, которую я заметил, это то, что я считаю, что код не обеспечивает никакой защиты для не перезаписывания страницы загрузчика. Вместо этого он полагается на инструмент DFU, чтобы не пытаться написать на этой странице. Поскольку DFU-UTIL, кажется, сначала проверяет, какие страницы можно записать, и только просит, чтобы в настоящее время он, кажется, работает, но я думаю, что это риск, что инструмент может запросить на страницу загрузчика, и загрузчик позволит это. Мне нужно прочитать больше кода, чтобы подтвердить это, но пока мое подозрение.

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

Спасибо, Виктор

Код регистра резервного копирования на самом деле не используется в Maple Bootloader. Кто -то послал мне его, и я подумал, что могу включить это, но также потребовалось изменение в ядре Libmaple, чтобы установить эти регистры до сброса - и я не изменил Libmaple, потому что из -за того, что я помню. Эскиз с использованием резервных регистров (как я думаю, они использовали их в своем эскизе)- хотя я не могу вспомнить детали.

Re: Bootloader перезаписывает себя

Да. Это нужно исправить.

Нашел эту интересную страницу на dfuse

http: // dfu-util.Sourceforge.net/dfuse.HTML


Re: Прыгайте на эскиз после загрузки

Я думаю, что каким -то образом встроенный загрузчик запускает код (от 0x8000000) после того, как я загружаю загрузчик (так как я загружаю его через свой собственный внутренний DFU)

Так похоже, что есть процесс для этого.

Это может быть команда сброса, отправленная от хоста, которая делает это, но это требует большего расследования.
Если это так, я подумал, что мы могли бы использовать регистр резервного копирования, чтобы, когда была получена команда сброса, она устанавливает значение флага, а MCU сбросится.
Затем мы можем добавить код в самом начале загрузчика, который проверяет этот флаг и немедленно прыгает на эскиз

Пса.
Я думаю, что значения флага резервного копирования, которые находятся в загрузчике, отличаются от значений в загрузчике Maple, поэтому я задавался вопросом, были ли они частью кода STM, а не что -то добавив Крис

Ппс.

Странно, если Крис написал загрузчику для работы с STM322ERIC, потому что вы не можете создать версию F4 STM32GERIERIERIERIERIERIERIER с векторным смещением, и я спросил Дэниела об этом и отправлю пиар, чтобы исправить это.

Но, как ни странно, есть неиспользованный файл линкера для платы Black F4 с смещением 0x4000, уже в репо

Смещение 0x4000, если я помню правильно для Aeroquad, но я не знаю, какой загрузчик они использовали. Я пытался найти источник, но не смог.
Chriss Offset на самом деле находится на 0x10000, который является пространством, зарезервированным примером STM -примером кода. Он не изменил эту часть.

Крисс упомянул, что написал это для STM32Generic. Он мог изменить ядро ​​достаточно, чтобы соответствовать его потребностям. Bootloader в основном неизменен из примера STM, за исключением того, что он переходит к коду пользователя после периода времени ожидания, и я считаю, что не видел этого в коде STM.

Я не уверен, но не будет ли нагрузка STM32GENERIERIERER, перенаправленная VTO? В этом случае, если сценарий линкера изменен для ссылки в 08004000, разве он не загрузил этот адрес в VTOR?
В противном случае он мог изменить свою копию ядра. В любом случае из того, что я видел в другом потоке, вы уже определили, какую часть ядра изменить, чтобы разрешить различные смещения.

Я думаю, что детали, которые нам нужно подтвердить/изменить:
1.- Убедитесь, что загрузчик не уничтожает себя (по массовому стиранию, написав на страницу)
2.- Подтвердите, что он прыгает на эскиз сразу после загрузки.
3.- Проверьте и подтвердите, поддерживает ли она команду сброса, и в этом случае она прыгнет к эскизу.

Возможно, вместо того, чтобы использовать регистры резервного копирования, мы могли бы зарезервировать первое слово в ОЗУ для волшебного слова.
Мы можем сделать это через сценарии линкера, так что переменные, куча и т. Д. Запуск 1 Word Up. Я не думаю, что это повредит, и это будет слово, которое никто никогда не должен пытаться изменить, так как, если оно не было зарезервировано, оно принадлежит переменной. Мы можем сделать это через сценарии линкеров и получить доступ только к указанию на этот адрес.

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

Я полностью согласен с вашим списком.

Убедитесь, что это не перезаписывает первое и т. Д

Re: резервные регистры против ОЗУ

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

Это может быть MCU очищает свою оперативную память, когда он становится мягким сбросом E.глин. NVIC сбросит, и, вероятно, делает то же самое из жесткого сброса в случае, если ОЗУ запустится со случайными значениями в нем.

Re: Сценарии VTOR и Linker

Это немного странно, потому что уже был сценарий линкера с смещением 0x4000 в общей папке варианта черного F4, но я ничего не мог видеть в досках.TXT, который использовал его.

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

Но охранник #IFDEF отсутствовал в файле запуска HAL, поэтому никто не мог создать версию с смещением без изменения локальной копии

Наверное, лучше всего запустить ветку в общем разделе STM32, и я также дает Даниэль, чтобы сообщить ему

Пса. Я собирался сделать пиар для охранника #ifdef, но я еще не сделал этого, так как мне нужно изолировать это изменение от моих досок.TXT изменить и проверить его первым, на моей локальной машине

Поскольку я не уверен, что Даниэль захочет пиар, чтобы добавить поддержку загрузчика, пока все это не работает

Ппс.

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

Роджер написал:Я также должен спросить Фредерика о внедрении тех же изменений в ядре STM, так как я подозреваю, что у них такая же проблема, когда пропал в охраннике, если ифдеф

Привет, Рик

Я не уверен, что ты имеешь в виду.

Первоначально мы искали сброс в встроенный загрузчик DFU в F4, так как для этого есть код, но если наброски сбои, вам нужно установить Boot0, чтобы снова попасть в загрузчик.

В конечном счете я знаю, что использование STLINK и т. Д. Лучше, но у большинства общих плат нет на борту STLINK, а загрузчик на F1 очень популярен и работает достаточно хорошо, учитывая отсутствие приличного USB -оборудования на общих платах

Код, который использует Victor, является собственным примером DFUSE от STM с некоторыми дополнениями, чтобы прыгнуть на эскиз

Недостатком использования кода HAL STM является то, что он гораздо больше, чем загрузчик Libmaple F1, а также ему нужен новый DFU-UTIL, который не совместим с загрузчиком Maple Bootloader

Я думаю, что загрузчик Maple F1 может быть изменен для запуска на F4, но это может потребовать много изменений / времени / усилий, следовательно, с помощью собственного кода DFUSE HAL Bootloader, казалось, был разумным вариантом

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

Но мне нужно заставить ядра вызвать сброс NVIC, когда они получат последовательность сброса магии, и только Generic STM32 уже имеет код для обращения с этим (на F4) - Libmaple F4 USB -код полностью отличается от F1, и ему нужно много Изменения, чтобы получить перезагрузку магического номера.

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

Следовательно, почему STM32 Generic выглядит лучшим начальным кантиром, чтобы добавить загрузчик DFUSE на основе Flash Dfuse

[Rogerclark - Вторник 29 августа 2017 3:20] - В конечном счете я знаю, что использование STLINK и т. Д. Лучше, но у большинства общих плат нет на борту STLINK, а загрузчик на F1 очень популярен и работает достаточно хорошо, учитывая отсутствие приличного USB -оборудования на общих платах

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

Большинство плат Nucelo даже не имеют нативного USB, подключенного к каким -либо внешним разъемам. Они предоставляют виртуальный COM-порт отладки, обычно подключенный к USART2, который просто работает.

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

[Rogerclark - Вторник 29 августа 2017 г. 3:20 утра] - но мне нужно заставить ядра для вызова NVIC сброса, когда они получают волшебную последовательность сброса, и только stm32 Generic уже имеет код, чтобы справиться с этим (на F4) - Libmaple F4 USB -код Совершенно отличается от F1, и потребуется много изменений, чтобы перезагрузить магическое число.

«Сброс волшебного сброса» меня беспокоит, так как это просто источник вопросов. "Почему я не вижу серийный порт на моем наброске мигания?" ... "Почему мой код не загружается после того, как я загружаю мигающий набросок?"Все сброс магии - это генерировать поток немного разных вопросов, которые все задают одно и то же .. Почему загрузчик не работает?

Рик

Point взят Re: собственное ядро ​​STM
Я не имею никакого отношения к этому развитию. Я сомневаюсь, что они хотели бы сбросить код сброса магического числа, так как он связывается с основным кодом.

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

STM32 Generic уже имеет сброс магического числа, поэтому кажется логичным расширить функциональность на F4

Виктор

К вашему сведению.

Я был слишком занят работой и т. Д., Чтобы многое сделать на загрузке.

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

Я нашел немного кода Hal Uart, поэтому я посмотрю, смогу ли я настроить USART 1 (PA9, PA10) в качестве терминала отладки.
Я думаю, что это должно быть достаточно быстро, чтобы распечатать какое-то сообщение о различных командах, которые DFU получает от DFU-UTIL

В качестве альтернативы, я рассматриваю просто бить данные с помощью формы SPI и использовать мой логический анализатор для просмотра SPI как текст.
(Это может быть легче работать, чем UART, а также принять гораздо меньше вспышки.)

Но даже если нам нужно сделать загрузчик немного больше для отладки, это не проблема, поскольку мы можем просто временно изменить смещение VECT на 0x6000 и т. Д. (И изменить линкер).

Затем измените его обратно, как только код работает и код UART был отключен.


Пса.

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

Самое простое решение - изменить

Flash_if_erase (.....) в USBD_DFU_FLASH.C и проверьте, какую страницу Flash он пытается стереть

А также изменить uint16_t flash_if_write (....)
Так что это тоже не пытается написать на страницы

КСТАТИ.
Предполагается, что DFUSE контролирует стирание и написание страниц отдельно.

Если мы получим любую из этих функций, чтобы вернуть 1, это должно отбросить ошибку обратно в DFU-UTIL

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

@Rick, общие и либмапл -ядра уже включают в себя часть, управляющую пакетом «волшебного», чтобы сбросить, так что нет ничего, если их добавить, чтобы добавить к ним.
Это, очевидно, не для досок в ядре, я согласен, что это бессмысленно, это для куча досок F4, которые не имеют на них Stlink. Даже если мы пропустим управление волшебным пакетом, наличие загрузчика, который работает автоматически и прыгает на эскиз, если загрузка не будет выполнена менее чем за X секунд, лучше, чем привязанность к бутанкам назад и вперед. Тем не менее, никому не обязаны использовать, это будет доступно для тех, кто хочет этого.

Лично я хочу использовать его, потому что, пытаясь использовать платы F4 в проектах, я хочу простой способ обновлять код без необходимости подключения отладчика или снаряжения с помощью бухга.
STM написал приложение, и оно работает довольно хорошо из коробки, не хватает тайм-аута в случае отсутствия загрузки и повторного разъединения USB, и он оставляет за собой намного больше памяти, чем необходимо по умолчанию (64 КБ, в то время как он подходит в 16).

Все мои комментарии были попыткой умолять вас: «Пожалуйста, оставьте Фредик и только ядро ​​STM, USB будет отличным» * или, по крайней мере, он будет реализован без необходимости какого -либо USB -кода сброса :) *

Я не говорил ни о ядре Libmaple, ни об общем ядре. Я говорю о официальном ядре STM, поддерживаемом.

Просто чтобы усложнить вещи

Интересно, является ли портирование загрузчика Maple Bootloader по -прежнему также вариант.

Кто-то уже разместил код для этого порта на один из этих сайтов с оплатой китайских исходных кодов.

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

это так странно...

Я уверен, что искал это раньше, но я только что нашел это

https: // github.com/gbulmer/openstm32sw/ ... загрузчик

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

В интересах я попытался собрать эту версию F4 версии Maple Bootloader, и вспыхнула на мою диско F4, но хотя светодиод мелькал, ничего не появилось на USB.

Я подозреваю, что код работает только с более старой версией GCC, как я помню, у нас были проблемы с оптимизацией с загрузчиком Maple (однако я думал GCC 4.8 было в порядке)

В этом случае я использовал GCC 4.8

Так что это не работает "из коробки" тоже

Я подозреваю, что это не функционально в F4, так как, похоже, у него есть установка Page_size до 2 КБ для любой конфигурации, а F405/7, а другие имеют большие размеры страниц.
Кроме того, официальная страница AEOQUAD32, по -видимому, указывает на загрузчик в этой плате (на основе F405) является внутренней. Есть инструкции по загрузке прошивки с использованием dfuse.

Виктор

Я согласен, это, возможно, никогда не сработало...

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

Я попытался найти, откуда взялся код, как упоминается в комментарии в Commit IST ALA42, но эта учетная запись GitHub совершенно пуста.

Я буду писать об этом, чтобы увидеть, пролил ли он Cam больше света на его статус


Пса. Причина, по которой я смотрел на это, заключалась в том, что он должен работать с существующими файлами DFU-UTIL и BAT и т. Д., Также он собирается менее 8K (но размер, если не так важен для F4)