xintrea

Я пытаюсь сделать эмулятор ПЗУ для клона Радио-86РК. Он подключается в разъем, на который выведена ША а ШД этого компьютера, и еще несколько системных сигналов. Под подключаемые внешние модули (эмулятор ПЗУ-это и есть внешний модуль) в компьютере отведено адресное пространство 8000h-BFFFh (объем 16Кб). Задача эмулятора ПЗУ - держать пины ШД, к котором подключен контроллер STM, в высокоимпендансном состоянии, и следить за адресом на ША. Если адрес попадает в обслуживаемый эмулятором диапазон, и приходит сигнал на чтение, пины ШД переводятся в состояние выхода и на них выставляется нужный байт. Длительность сигнала на чтение - 500нс. Все. Такой контроллер не подойдет, одна только эмулируемая прошивка будет занимать 16Кб программной памяти.

Да, там реально 72MHz устанавливается. Функция инициализации такая же как и здесь: https://webhamster.ru/mytetrashare/index/mtb0/1649356037vhemuctihu и на ноге 12 в этом коде реально 60нс на осциллографе видно. Где про обязательность задержки можно прочитать? Что-то в даташите не нашел таких ограничений. Да, частота видимых миганий изменяется в двое. Ну какой ШИМ, там же просто включется-выключется нога с задержкой. Можете предложить другой метод? На таком оборудовании через прерывания ловить события не получится, потому что только на вход в прерывание больше 500нс уходит. Если приплюсовать сюда выход и задержку прохода сигнала прерывания, то получится что с прирываниями работать вообще не вариант. А методом опроса можно ловить события, и еще 15-25 тактов останется на логику, а мне больше и не надо.

В общем, проверил. Функция msDelay() в обеих случаях закомпилилась одинаково, байт в байт: Я же для микроконтроллера компилю, по дефолту оптимизация по размеру.

Опции компиляции всех проектов у меня одинаковые. Оптимизация везде -Os и все. Или хотите сказать, что в разном окружающем коде компилятор будет по-разному компилировать msDelay?

Привет, народ! Заметил такую странность, которую не знаю как объяснить. Плата STM32F103C8T6 (Blue Pill) Я хотел сделать мигание светодиодом на ноге A0 при инициализации контроллера на 72MHz. Взял сделанный ранее проект и стал его упрощать. И вот когда оставил в проекте, по-сути, только: - инициализацию на 72Mhz - включение тактирования портов - настройку пина A0, то заметил, что код мигания стал работать медленнее! Т. е. мигание, сделанное в бесконечном цикле, стало в 1.5-2 раза медленнее, чем было до. Я стал разбираться, что могло на это повлиять. И вернул вызов ненужной функции, в которой инициализировались пины A8, A9, B3, B4, B6, B7. И о чудо, мигание стало опять быстрым! Повторюсь, в этой функции делается только инициализация пинов, и она вызывается один раз в начале программы, ничего более. Вот полный код: https://pastebin.com/Z7d0LZif А вот код функции, которая "разгоняет" выполнение кода: // Настройка пинов A8, A9, B3, B4, B6, B7 void otherPortInit(void) { // Для начала сброс конфигурации всех используемых портов в ноль GPIOA->CRH &= ~(GPIO_CRH_MODE8 | GPIO_CRH_CNF8); GPIOA->CRH &= ~(GPIO_CRH_MODE9 | GPIO_CRH_CNF9); GPIOB->CRL &= ~(GPIO_CRL_MODE3 | GPIO_CRL_CNF3); GPIOB->CRL &= ~(GPIO_CRL_MODE4 | GPIO_CRL_CNF4); GPIOB->CRL &= ~(GPIO_CRL_MODE6 | GPIO_CRL_CNF6); GPIOB->CRL &= ~(GPIO_CRL_MODE7 | GPIO_CRL_CNF7); uint32_t mode; uint32_t cnf; mode=0b11; // Режим выхода, с максимальной частотой 50 МГц cnf=0b00; // Режим push-pull GPIOA->CRH |= (mode << GPIO_CRH_MODE8_Pos) | (cnf << GPIO_CRH_CNF8_Pos); GPIOA->CRH |= (mode << GPIO_CRH_MODE9_Pos) | (cnf << GPIO_CRH_CNF9_Pos); mode=0b00; // Режим входа cnf=0b01; // Режим плавающего входа, подтяжки нет GPIOB->CRL |= (mode << GPIO_CRL_MODE3_Pos) | (cnf << GPIO_CRL_CNF3_Pos); GPIOB->CRL |= (mode << GPIO_CRL_MODE4_Pos) | (cnf << GPIO_CRL_CNF4_Pos); GPIOB->CRL |= (mode << GPIO_CRL_MODE6_Pos) | (cnf << GPIO_CRL_CNF6_Pos); GPIOB->CRL |= (mode << GPIO_CRL_MODE7_Pos) | (cnf << GPIO_CRL_CNF7_Pos); } Я не могу эту вещь объяснить. Почему настройки пинов, которые не используются в коде, так странно влияют на скорость выполнения программы контроллером? Мало того, в базовом проекте, на точно таком же коде я обнаружил обратный эффект: вызов этой функции инициализации портов замедляет мигание, а комментирование ее вызова - ускоряет. В общем, я в недоумении. Я вообще не ожидал, что такое поведение возможно. Это тормозит разработку домашнего проекта, потому то в нем критична реакция на сигналы длительностью ~500нс, и тут я вижу, что тупой бесконечный цикл работает с разной скоростью в зависимости от инициализации неиспользуемых портов. Вопрос 1: Как единственный вызов этой функции может влиять на скорость выполнения основного цикла? Вопрос 2: Почему вызов этой функции может давать строго обратный эффект?

Я прозвонил контакты, которые находятся по середине джамперов. Коммутация следующая: Контакт boot0 - R3 - ножка 44 (в даташите BOOT0) Контакт boot1 - R4 - ножка 20 (в даташите PB2) Это соответствует и уже приведенной картинке BluePill, и другой, более полной картинке: Получается, что если сброс произошел в положении boot0=0 boot1=1, то это действительно недокументированное положение, которое по таблице в мануале не отличается от положения 00. Я ни на что не претендую, но по моим данным выходит, что в мануале перепутаны столбцы. Тем более, что такое недокументированное положение используется в DFU-bootloader, чтобы загнать его в режим ожидания получения прошивки по USB. И плата действительно при boot0=0 boot1=1 переводит DFU-bootloader в режим, когда он видится как USB-устройство. Либо я уже устал и что-то напутал.

Я не уверен, что понял что произошло, но получилось сбросить. Тыкал и так и эдак, но сбросилось именно тогда, когда я поставил перемычки так: boot0 [o-o]o boot1 o[o-o] Картинка нам говорит, что сверху boot0, снизу boot1: А это значит, что был выставлен boot0=0, boot1=1, и согласно Reference Manual такое положение неотличимо от "нуливого" 00 (не забываем, в таблице boot1 в левом столбце). Но именно в таком положении я прошил с зажатым Reset мигалку, после чего при "нуливом" положении перемычек 00 плата стала стартовать с правильным объемом FLASH/RAM и с правильным id. Неясно, где закралась ошибка: толи в Reference manual, то ли на картинке boot0 должен быть снизу, boot1 - сверху. Толи я в Reference manual не вижу что про вариант boot0=0 boot1=1 написано, что он может использоваться при проблемах для сброса.

Не понял, так на деле два пина: https://webhamster.ru/mytetrashare/index/mtb0/16450373484keh0oad29 И в reference manual имеем: Я пользуюсь "RM0008 Reference manual STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced Arm ® -based 32-bit MCUs". Я тоже думал что будет просто, ставил перемычки в положение 00 и 01 (как по таблице, в ней boot1 в левом столбце, не все на это внимание обращают). 11 ставить бессмысленно. Но толку никакого ни так ни эдак. Перемычки влияют только на место, откуда идет загрузка, не более того. Положение 01 нужно чтобы запустился UART-бутлоадер из ROM, в положении 00 ничего не запустится потому что FLASH пустой, я это показал. То есть, никакой левый код при старте контроллера не выполняется. Но контроллер все равно показывает flash:0, sram:0, chipid:0x0748. Такой chipid ни один прошивальщик не знает. Из-за этого chipid контроллер и невозможно прошить в "обычном" режиме. Модификация памяти возможна только при зажатом Reset, потому что тогда chipid становится адекватным 0x0410. Но нельзя же контроллер все время использовать с нажатым Reset, это же ненормально.

Что непонятно в моем вопросе и в подробном описании действий, которые я произвожу с платой?

Имею плату STM32F103C8T6 (Blue Pill). После прошивки в контроллер DFU-бутлоадера и поигравшись с ним, решил прошить контроллер своей программой по-обычному, через ST-LinkV2 (SWD). Поставил boot-джамперы в положение 00, и попытался прошить через ST-Link. И каково же было мое удивление, что я этого сделать не могу по причине некорректного chipid. До прошивки DFU-bootloaderа плата выдавала такие данные: > st-info --probe Found 1 stlink programmers serial: 132014026315303030303032 openocd: "\x13\x20\x14\x02\x63\x15\x30\x30\x30\x30\x30\x32" flash: 65536 (pagesize: 1024) sram: 20480 chipid: 0x0410 descr: F1 Medium-density device А после работы с DFU-прошивкой плата стала выдавать такое: Found 1 stlink programmers serial: 132014026315303030303032 hla-serial: "\x13\x20\x14\x02\x63\x15\x30\x30\x30\x30\x30\x32" flash: 0 (pagesize: 0) sram: 0 chipid: 0x0748 И в момент прошивки по SWD STLinkV2 дает теперь такую ошибку: > st-flash --reset write myprogramm.bin 0x08000000 st-flash 1.6.1 2022-04-09T18:48:44 WARN common.c: unknown chip id! 0x3748 Failed to connect to target (И что еще непонятно, в st-info виден идентификатор 0x0748, а флешер ругается на идентификатор 0x3748). Начал искать советы, как сбросить плату. Советы были разные, ни один не сработал. Вот что я делал: * * * Вначале выставил boot-перемычки на boot0=1 и boot1=0 чтобы при старте платы не выполнялся левый код, переткнул плату в USB-гнезде и попытался обнулить FLASH. Но нет, такое не прокатывает: > st-flash erase st-flash 1.6.1 2022-04-09T18:57:41 WARN common.c: unknown chip id! 0x3748 Failed to connect to target Пробовал с boot-перемычками в положении 00, тот же самый результат. В конце концов заметил, что если нажать Reset и удерживать, плата начинает выдавать такую информацию о себе: Found 1 stlink programmers serial: 132014026315303030303032 hla-serial: "\x13\x20\x14\x02\x63\x15\x30\x30\x30\x30\x30\x32" flash: 61010944 (pagesize: 1024) sram: 20480 chipid: 0x0410 descr: F1xx Medium-density Странный размер FLASH, но зато chipid правильный. Удерживая Reset, дал команду очистки FLASH и она сработала: > st-flash erase st-flash 1.6.1 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 59581 KiB flash in at least 1 KiB pages. Дальше перегрузил плату, но она все равно опять показывает flash:0, sram:0, chipid:0x0748. Я пытался проделать то же самое с boot-перемычками Boot0=1 Boot1=0, результат тот же. Тогда при нажатом Reset я проверил, а что вообще в FLASH памяти есть: > st-flash read firmware.bin 0x8000000 0x2000 > xxd firmware.bin 00000000: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000010: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000020: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000030: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000040: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000050: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000060: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000070: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000080: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 00000090: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... 000000a0: 08b5 1420 08b5 1420 08b5 1420 08b5 1420 ... ... ... ... ... Прошивки уже нет. Но все равно плата показывает flash:0, sram:0, chipid:0x0748 пока не зажмешь Reset. Я пробовал зажимать Reset до вставки ST-LinkV2 в USB, пробовал не зажимать, пробовал нажимать один раз, с разными положениями boot-перемычек, давал команды st-flash erase, st-flash reset, но все бестолку. Плата упорно показывает flash:0, sram:0, chipid:0x0748. Вопрос: как, блин, эту плату можно сбросить? Чтобы вернулся нормальный id и правильный размер FLASH/RAM?

И кстати, при джамперах boot0=0 boot1=0 COM-порт отвечает. Вот что он показывает: Congratulations, you have installed the STM32duino bootloader See https://github.com/rogerclarkmelbourne/STM32duino-bootloader For more information about Arduino on STM32 See https://www.stm32duino.com Осталось только понять, почему загрузчик при заливке программы перетирает свой хвост. * * * UPD: Похоже, начал понимать что происходит. Образ предкомпиленного DFU-bootloaderа на самом деле не чистый DFU-bootloader, а DFU-bootloader + программа эмуляции COM-порта на USB. Сам DFU-butloader имеет длинну примерно 0x1c00. А программа эмуляции COM-порта начинается со смещения 0x2000. и тянется до 0x56fc. То есть, DFU-bootloader не имеет двух режимов. То, на что я наткнулся вначале и думал что является вторым режимом (при обоих boot джамперов в нуле) - это на самом деле просто работа программы эмуляции COM-порта. Получается, что для заливки программы можно пользоваться даже устройством Upload to Flash 0x8002000, не обязательно даже Upload to Flash 0x8005000, все равно никакой хвост загрузчика затираться не будет. "Чистый" DFU-загрузчик лежит не в каталоге /binaries, а в каталоге /bootloader_only_binaries. То есть, для платы STM32F103C8T6 ссылка на DFU-бутлоадер в данном проекте будет такой: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/bootloader_only_binaries/generic_boot20_pc13.bin * * * Теперь осталось разобраться, как компилировать программы с начальным адресом 0x8002000 вместо классических 0x8000000, и можно будет проверять заливку по DFU.

И все-таки поддерживает. Я разобрался в чем дело было. Чтобы включился DFU-режим, надо поставить джампера boot в недокументированное состояние: boot0=0, boot=1. Этот момент уже просили добавить в документацию/описание, но автор делать этого почему-то не стал: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/90 После этого плата по USB (после нажатия Reset и перетыкания в USB-генезде) начинает видиться по-другому: [ 4304.984940] usb 2-2: new full-speed USB device number 35 using xhci_hcd [ 4305.133726] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01 [ 4305.133733] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4305.133735] usb 2-2: Product: Maple 003 [ 4305.133738] usb 2-2: Manufacturer: LeafLabs [ 4305.133739] usb 2-2: SerialNumber: LLM 003 И начинает работать dfu-util: > dfu-util --list Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000", serial="LLM 003" Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000", serial="LLM 003" Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=0, name="STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.", serial="LLM 003" Однако далее возникает проблема. Длина DFU-загрузчика 0x56fc, значит, если он прописывается во FLASH с 0x8000000, то он будет занимать область вплоть до адреса 0x80056fc. И при этом сам DFU-загрузчик предоставляет возможность прошивать, начиная с адреса 0x8005000. Вот это как понимать? Получается, что сам себе затрет хвост. Или я чего-то не догоняю?

Привет, народ. Пытаюсь разобраться как прошивать плату STM32F103C8T6 (Blue Pill) по miniUSB-кабелю. Свои изыскания я записываю здесь: Как прошивать Blue Pill STM32 F103 через обычный USB-кабель в Linux Затык происходит на том, что я прошиваю DFU-бутлоадер в плату, плата становится видна по USB: [25760.232130] usb 2-2: new full-speed USB device number 7 using xhci_hcd [25760.385437] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00 [25760.385444] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [25760.385447] usb 2-2: Product: Maple [25760.385449] usb 2-2: Manufacturer: LeafLabs [25760.424009] cdc_acm 2-2:1.0: ttyACM0: USB ACM device [25760.424307] usbcore: registered new interface driver cdc_acm [25760.424310] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Однако утилита dfu-util (версии 0.9) ни одной платы не видит. И версия 0.8 тоже не видит: > dfu-util --list dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Пробовал давать команду с указанием id-шников устройства: dfu-util -d 1eaf:0004 --list так тоже DFU-устройство не обнаруживается. Пробовал и под рутом, и от обычного пользователя, хотя DBUS правило для доступа пользователем прописывается при установке пакета dfu-util (Debian Linux 11). Что еще нужно донастроить, чтобы увидеть DFU-устройство?

В общем, бросил я ковыряться с STM32CubeIDE и по-началу продолжил свои изыскания на базе Qt Creator и свободного софта. В результате получилось нечто: Настройка QtCreator для программирования и отладки STM32F103 (Blue Pill) в Debian Linux И этот результат меня не порадовал. Нужно иметь STM32CubeIDE для создания базового проекта. А потом его нужно перетягивать в Qt Creator, и это не то, что хотелось бы получить от IDE. В общей сложности на эти изыскания у меня ушло несколько месяцев, так как я периодически возвращался к этому вопросу, но ничего не получалось. * * * Но в конечном итоге я нашел то, что нужно: это связка VS Code и PlatrormIO: Настройка VS Code + PlatformIO для программирования и отладки STM32F103 (Blue Pill) под Linux Такое решение оказалось и удобнее и проще в настройке чем QtCreator.

В какой конфиг (желательно, путь к файлу) и какую строчку добавлять?