Jump to content
    

xintrea

Участник
  • Posts

    25
  • Joined

  • Last visited

Everything posted by xintrea


  1. Я пытаюсь сделать эмулятор ПЗУ для клона Радио-86РК. Он подключается в разъем, на который выведена ША а ШД этого компьютера, и еще несколько системных сигналов. Под подключаемые внешние модули (эмулятор ПЗУ-это и есть внешний модуль) в компьютере отведено адресное пространство 8000h-BFFFh (объем 16Кб). Задача эмулятора ПЗУ - держать пины ШД, к котором подключен контроллер STM, в высокоимпендансном состоянии, и следить за адресом на ША. Если адрес попадает в обслуживаемый эмулятором диапазон, и приходит сигнал на чтение, пины ШД переводятся в состояние выхода и на них выставляется нужный байт. Длительность сигнала на чтение - 500нс. Все. Такой контроллер не подойдет, одна только эмулируемая прошивка будет занимать 16Кб программной памяти.
  2. Да, там реально 72MHz устанавливается. Функция инициализации такая же как и здесь: https://webhamster.ru/mytetrashare/index/mtb0/1649356037vhemuctihu и на ноге 12 в этом коде реально 60нс на осциллографе видно. Где про обязательность задержки можно прочитать? Что-то в даташите не нашел таких ограничений. Да, частота видимых миганий изменяется в двое. Ну какой ШИМ, там же просто включется-выключется нога с задержкой. Можете предложить другой метод? На таком оборудовании через прерывания ловить события не получится, потому что только на вход в прерывание больше 500нс уходит. Если приплюсовать сюда выход и задержку прохода сигнала прерывания, то получится что с прирываниями работать вообще не вариант. А методом опроса можно ловить события, и еще 15-25 тактов останется на логику, а мне больше и не надо.
  3. В общем, проверил. Функция msDelay() в обеих случаях закомпилилась одинаково, байт в байт: Я же для микроконтроллера компилю, по дефолту оптимизация по размеру.
  4. Опции компиляции всех проектов у меня одинаковые. Оптимизация везде -Os и все. Или хотите сказать, что в разном окружающем коде компилятор будет по-разному компилировать msDelay?
  5. Привет, народ! Заметил такую странность, которую не знаю как объяснить. Плата 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: Почему вызов этой функции может давать строго обратный эффект?
  6. Я прозвонил контакты, которые находятся по середине джамперов. Коммутация следующая: Контакт boot0 - R3 - ножка 44 (в даташите BOOT0) Контакт boot1 - R4 - ножка 20 (в даташите PB2) Это соответствует и уже приведенной картинке BluePill, и другой, более полной картинке: Получается, что если сброс произошел в положении boot0=0 boot1=1, то это действительно недокументированное положение, которое по таблице в мануале не отличается от положения 00. Я ни на что не претендую, но по моим данным выходит, что в мануале перепутаны столбцы. Тем более, что такое недокументированное положение используется в DFU-bootloader, чтобы загнать его в режим ожидания получения прошивки по USB. И плата действительно при boot0=0 boot1=1 переводит DFU-bootloader в режим, когда он видится как USB-устройство. Либо я уже устал и что-то напутал.
  7. Я не уверен, что понял что произошло, но получилось сбросить. Тыкал и так и эдак, но сбросилось именно тогда, когда я поставил перемычки так: 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 написано, что он может использоваться при проблемах для сброса.
  8. Не понял, так на деле два пина: 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, это же ненормально.
  9. Что непонятно в моем вопросе и в подробном описании действий, которые я произвожу с платой?
  10. Имею плату 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?
  11. И кстати, при джамперах 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.
  12. И все-таки поддерживает. Я разобрался в чем дело было. Чтобы включился 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. Вот это как понимать? Получается, что сам себе затрет хвост. Или я чего-то не догоняю?
  13. Привет, народ. Пытаюсь разобраться как прошивать плату 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-устройство?
  14. В общем, бросил я ковыряться с STM32CubeIDE и по-началу продолжил свои изыскания на базе Qt Creator и свободного софта. В результате получилось нечто: Настройка QtCreator для программирования и отладки STM32F103 (Blue Pill) в Debian Linux И этот результат меня не порадовал. Нужно иметь STM32CubeIDE для создания базового проекта. А потом его нужно перетягивать в Qt Creator, и это не то, что хотелось бы получить от IDE. В общей сложности на эти изыскания у меня ушло несколько месяцев, так как я периодически возвращался к этому вопросу, но ничего не получалось. * * * Но в конечном итоге я нашел то, что нужно: это связка VS Code и PlatrormIO: Настройка VS Code + PlatformIO для программирования и отладки STM32F103 (Blue Pill) под Linux Такое решение оказалось и удобнее и проще в настройке чем QtCreator.
  15. В какой конфиг (желательно, путь к файлу) и какую строчку добавлять?
  16. Не понял, у меня везде Linux стоит. Это хорошо или плохо? В нем стоит проприетарная среда от производителя STM32CubeIDE. Это хорошо или плохо?
  17. Происходит следующее: 1. Я меняю конфиг, сохраняю изменения в файле. 2. Запускаю Build All 3. Запускаю Run 4. Вначале отрабатывает какая-то сборка, вижу надпись finish building, затем происходит попытка запуска. В этот момент конфиг-файл прямо на экране меняется на дефолтное значение, которое я показал выше, только сверху прилепляется заголовок: # This is an genericBoard board with a single STM32F103C8Tx chip # # Generated by STM32CubeIDE # Take care that such file, as generated, may be overridden without any early notice. # Please have a look to debug launch configuration setup(s) Я залез в настройки Debug Configuration, и переставил галку в Configuration Script с Automated Generation на User Defined. Снова прописал вашу конфигурацию, пересобрал, запустил. В результате вылазит ошибка: Error in final launch sequence: Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Время ожидания соединения истекло. Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Время ожидания соединения истекло. localhost:3333: Время ожидания соединения истекло. Скриншот с этой ошибкой прикреплен. Если же переставить отладчик с STLink (OpenOCD) на STLink GDB Server, то запуск завершается такой ошибкой: Error in final launch sequence: Failed to start GDB server Failed to start GDB server Error in initializing ST-LINK device. Reason: (18) Could not verify ST device! Abort connection. Куда дальше ковырять?
  18. Поковырялся, и нашел файл конфига проекта, прямо в корне проекта, который называется <имя_проекта>.cfg. Видимо, вы его имели в виду. Сейчас конфиг выглядит так (еще не редактировал): source [find interface/stlink-dap.cfg] set WORKAREASIZE 0x5000 transport select "dapdirect_swd" set CHIPNAME STM32F103C8Tx set BOARDNAME genericBoard # Enable debug when in low power modes set ENABLE_LOW_POWER 1 # Stop Watchdog counters when halt set STOP_WATCHDOG 1 # STlink Debug clock frequency set CLOCK_FREQ 8000 # Reset configuration # use software system reset if reset done reset_config none set CONNECT_UNDER_RESET 0 set CORE_RESET 0 # ACCESS PORT NUMBER set AP_NUM 0 # GDB PORT set GDB_PORT 3333 # BCTM CPU variables source [find target/stm32f1x.cfg] Вопрос: его полностью надо заменить, или редактировать отдельные строки?
  19. Не пойму, что нужно сделать. Нужно найти файл interface/stlink.cfg и в нем обеспечить наличие строк transport select hla_swd #ALI chip fake set CPUTAPID 0x2ba01477 И нужно найти файл target/stm32f1x.cfg, и обеспечить в нем наличие строки: reset_config connect_assert_srst Так? Или весь ваш код - это законченный конфиг? Но тогда в каком конфиг-файле этот текст должен находиться? Или это нужно понатыкать в интерфейсе проекта в STM32CubeIDE?
  20. Привет, народ. Купил себе на пробу STM32F103C8T6 (BluePill) с программатором STLink-V2. Вот что о нем рассказывает 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 Установил среду STM32CubeIDE Version: 1.8.0 Build: 11526_20211125_0815 (UTC). И попытался собрать и запустить программку мигания светодиодом. Сделал новый проект для STM32F103C8Tx, настройки брал из вот этого видео: https://www.youtube.com/watch?v=e_NSqz5P8Qk По-сути сгенерировался дефолный проект для STM32F103C8Tx, частота настроена на 72MHz, активирован пин PC13 на режим Output. В коде в бесконечный цикл вписаны команды: while (1) { HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); HAL_Delay(500); } По ходу попыток запуска, вначале STM32CubeIDE сказал, что прошивка устарела, и надо обновить. Я согласился, но пришлось пару раз вставить-вытащиить программатор в USB, так как была ошибка: st-link is not in the DFU mode. Please restart it. Прошивка залилась, а в сети нашел инфу что если обновление прошивки предваряется такой ошибкой, то это нормально. Потом пришлось подредактировать файл stm32f1x.cfg, так как при запуске была ошибка: linux gdb ST-LINK: Could not verify ST device! Abort connection. Эту ошибку убрал по инструкции: https://stackoverflow.com/questions/58783393/atollic-couldnt-verify-st-device, заодно отладку переключил с STLink GDB Server на STLink OpenOCD (сам GDB, естественно, установлен и работает, обычный C/C++ код через него отлаживается). В результате, после устранения предыдущей ошибки, стали появляться другие ошибки: Error: STM32F103C8Tx.cpu -- clearing lockup after double fault Polling target STM32F103C8Tx.cpu failed, trying to reexamine Насколько я понял, эти ошибки возможны из-за того, что программа либо не запускается, либо крашится уже на самом микроконтроллере по причине неправильной настройки диапазонов адресного пространства или какой-то периферии. Тогда я решил снова сделать новый проект, все повторил заново, и на этот раз почти получилось. Во всяком случае, явных ошибок в логе запуска нет. Но светодиод не мигает, отладка не работает: Open On-Chip Debugger 0.11.0+dev-00438-ga75fc63 (2021-11-03-15:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 2.427853 Info : Unable to match requested speed 8000 kHz, using 4000 kHz Info : Unable to match requested speed 8000 kHz, using 4000 kHz Info : clock speed 4000 kHz Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x2ba01477 Info : STM32F103C8Tx.cpu: Cortex-M3 r2p1 processor detected Info : STM32F103C8Tx.cpu: target has 6 breakpoints, 4 watchpoints Info : starting gdb server for STM32F103C8Tx.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 Info : device id = 0x20036410 Info : flash size = 64kbytes undefined debug reason 8 - target needs reset O.K. O.K.:0xE00FFFD0 undefined debug reason 8 - target needs reset shutdown command invoked Info : dropped 'gdb' connection Я пробовал собрать и запуститься в режиме релиза (переткнул и конфигурацию и билд на Release), но почему-то при запуске RUN все равно IDE пытается запустить дебаггер, ей это не удается, лог запуска все тот же. Дальше я уже не знаю что делать. Прошу посоветовать что где еще надо докрутить, чтобы помигать светодиодом. * * * UPD: Иногда запуск почему-то происходит по-другому, хотя ничего ни в коде ни в конфигурации не меняю. Запуск сопровождается появлением окна с ошибкой: Could not verify STM device! Хотя, как написано выше, такая ошибка была, и верификация устройства отключена (в начало файла stm32f1x.cfg добавлена строка set CPUTAPID 0). Выхлоп запуска при этом немного другой, строки с Info те же самые, но в конце такие ошибки: undefined debug reason 8 - target needs reset O.K. O.K.:0xE00FFFD0 Error: Failed to read memory at 0xfffffffe Error: Failed to read memory at 0xfffffffe undefined debug reason 8 - target needs reset shutdown command invoked Info : dropped 'gdb' connection Вот как выглядит скриншот: https://ibb.co/JvyD2HK
  21. Нет, это задано именно программно. Во-первых, никакого перелистывания нет в играх, оно только в меню и подменю. Во-вторых в документации написано: То есть, это гениальное решение китайских специалистов по юзабилити. А может быть эффективные менеджеры потребовали такое поведение, чтобы сразу при включении компьютер показыва как много в него напихано.
  22. Хотите сказать, что под большой каплей две микрухи - память и микроконтроллер?
  23. Да у него есть и ноутбук, и планшет. А этот комп - он классный тем, что низкоуровневый. Если бы не это уродство - был бы неплохой девайс. А так - на свалку.
  24. Извиняюсь, если ошибся разделом. Родственники подарили ребенку детский компьютер под брендом "Фиксики". Вот такой: http://www.detmir.ru/product/index/id/159652/ http://www.youtube.com/watch?v=s56FbzGL3pU Впринципе, компьютер неплохой, интересно смотреть на теплый ламповый ЖК экран, ребенок сразу удивился что изображение можно формировать из квадратиков. Есть неплохие игры. Вещь в себе. Но есть один раздражающий недостаток в интерфейсе, из-за которого я запретил ребенку играть на нем и разобрал его. Проблема в том, что этот компьютер не позволяет сосредоточиться на работе с ним. Меню устроено таким образом, что раз в две секунды оно автоматически перелистывается с мерзким звуком. То есть, меню можно листать клавишами, но если более двух секунд не листаешь, оно само начинает перелистываться по кругу. То же самое и во всех подменю. То есть, пока выберешь что тебе нужно, измучаешься. Нужно либо с дикой скоростью перетыкаться в меню, либо постоянно перелистывать обратно на нужный пункт меню, который (пока человек раздумывал) успевает перелистнуться несколько раз. Перечитал всю инструкцию. Нигде нет отключения этого режима. В интернете нет никаких данных по возможной настройке. Мне ничего не остается, как попробовать модифицировать прошивку, и убрать это недоразумение. Ребенок просит отдать комп, но я либо его доломаю, либо исправлю. В компе есть две платы. ----- Материнская плата с двумя бескорпусными микросхемами: http://i.piccy.info/i9/8ee1b07c69417f2f112...P1110671_01.jpg http://i.piccy.info/i9/bc122b3a0985addefcd...P1110674_01.jpg Я не большой знаток микроэлектроники, но если бы я делал такой комп, я бы использовал какую-нибудь 8-битную AVR-ку типа AVR XMEGA. Вопрос в том, влезет ли в ~380Кб набортной памяти все звуковые оцифровки в каком-то формате. Звуков, музыки и фраз на русском и английских языках достаточно много. Возможно, что вторая микруха - это ПЗУ я хз. Слышал, что для AVR есть либы по работе с FAT, что внешнее ПЗУ - это типа винта, вобщем не знаю. Либо в качестве микроконтроллера используется что-то более современное с 32-х битной архитектурой типа STM32 и хотя бы с мегабайтом flash мозгов. В бытность DOS я бы мог засунуть в 1Мб несколько минут звуковой оцифровки с приемлемым качеством. В этом случае назначение второй микрухи для меня загадка. Или на плате какой-то MIPS? Плата односторонняя, и похоже что однослойная. На плате не нашел тактового генератора. Под черной резинкой ничего интересного - резисторы, диоды, с обратной стороны платы припаян транзистор S8550 D331 (добавил второе фото без резинки). Три электролитических кондера в прорезанных окошечках. Сверху гребенка контактов идет на ЖК экран, экран накрывает всю эту плату. Сбоку пропаянные контакты от конроллера клавиатуры. На плате две надписи PL-1590JSMA0-1 и AEC1222. В интернете по этим обозначениям ничего не находится. ----- Контроллер клавиатуры - это вторая плата. http://i.piccy.info/i9/192ed57e15bfae9b93c...P1110673_01.jpg Одна бескорпусная микруха. На плату заведены сигналы с клавиатуры и "мышки" - джойстика (черные открытые контакты - это они). Сверху пропаянные контакты уходят на материнку. Тактового генератора нет. Плата односторонняя, однослойная. На плате обозначение PL-1590JSMB01-4, тоже ничего в интернете нет. ----- Вопрос 1. Что за архитектура, по вашему мнению, скрывается в бескорпусных микросхемах на материнке? Каково назначение большой и малой микрухи на материнке? Вопрос 2. Реально ли вытащить из (видимо большой) микрухи прошивку, и засунуть ее обратно модифицированную? На материнке есть какие-то три здоровых перемычки, возможно это JTAG, никогда с такой штукой не работал, но если надо разберусь. В интернете правда натыкался и на двухпроводной RX/TX JTAG и на шестипроводной JTAG... Вопрос 3. Похожи ли эти перемычки на контакты JTAG? Ели похожи, надо ли их перерезать? К каким контактам подключаться после перезки? К верхним или нижним (склоняюсь к верхним). Как определить куда подключать RX, куда TX? Вопрос 4. Реально ли декомпилировать/отдебажить прошивку, чтобы найти место, где перетыкаются пункты меню? Я бы попробовал изменить условие, чтобы оно никогда не срабатывало по таймеру. Я под виндой подламывал несколько программ через SoftICE и OllieDebugger, представление об ассемблерах и машинном коде имею. Какой софт посоветуете (лучше опенсорч и под линух). Вопрос 5. Реально ли залить прошивку по JTAG обратно? Или производители обычно делают непрошиваемыми такие устройства? Чем лить? Avrdude справится или нужно что-то другое? UPD: Добавил фото материнки без резинки.
×
×
  • Create New...