Comments 37
gdb в них собран без поддержки Python'а, что делает невозможной отладку через QtCreator
Я с этой проблемой столкнулся, оказалось, что она решается очень просто и быстро. Как правило, под разные системы (ту же винду, в частности) есть собранные версии gdb с поддержкой python (например, под ту же винду есть собранный gdb на сайте qt-project http://download.qt-project.org/official_releases/gdb). А в настройках комплекта в QtCreator можно этот отладчик явно указать. Profit!
З.Ы.
Например, вот здесь есть статейка, в конце которой упоминается собранный gdb с поддержкой arm и python, можно его попробовать.
Как-то задавался этим вопрос и получал ответы такого вида: «У нас нету много времени чтобы изучать Ваши новые IDE, Toolchains и тд., так как нас полностью устраивает то, что идет „с коробки“ от производителя. Все свое основное время мы лучше потратим на аппаратный мир (то есть, сам МК) и его изучение.»
Но пользуясь случаем хотел бы задать такие вопросы (извиняюсь за небольшой «оффтоп»):
- Как часто Вам приходиться «билдить» или «дебажить» с консоли?
- Была бы Вам интерестна платформа STM32 в PlatformIO?
Всем большое СПАСИБО!
Видимо это тоже все как-то связанно с тем, что и инструментарий крайне неудобен для программирования (сравните Keil, IAR с тем же XCode).
- Билдить почти никогда, хотя qbs это прекрасно умеет, а вот дебажить пару раз приходилось.
- Я бы лучше дальше занялся улучшением поддержки embedded платформ со стороны qbs и QtCreator
Читаете мои мысли :)
>> Я бы лучше дальше занялся улучшением поддержки embedded платформ со стороны qbs и QtCreator
Спасибо. Буду следить.
P.S: Извиняюсь, ответ к #comment_7703313
HSE_VALUE — это не частота ядра, это частота кварца, которая чаще всего 8MHz (8000000) или 25MHz."HSE_VALUE=168000000"
Почему может так быть что МК не прошивается? Но отладка работает. Код в МК не соответствует ожидаемому явно.
А прошивка же вообще другими методами осуществляется, я ее всегда через dfu-util делал.
В общем разрулил. У меня был прошитый ST-Link в J-Link. Очевидно что JLink гораздо круче по скорости и возможностям. Отладка работала но как-то туповато, точки останова не всегда срабатывали. Прошивка командой от GDB load. Приводила к фэйлу, но отладка начиналась, естественно не соответствуя .elf-файлу. Несколько раз я прозревал от разных фич:
Блокировка флэш — защита от записи — write protection. Убирается командой
(gdb) monitor flash protect bank sector_begin sector_end off # sector=page - см.доки на МК.
Например STM32F1 имеет страницы размером по 2кБ, и для МК с 256кБ флэша нужно задать 0 0 127. Для STM32F4 с 1МБ, у него сектора разного размера будут 0 0 11. У каждого МК свой фокус.
Посмотреть чё как
monitor flash info 0 # bank=0
При работе напрямую через
openOCD, например задавая команды черезxxx.cfgили опцию-cили telnet всё то же самое но без словаmonitor
- Это помогло 1 раз. Короче прошивалось нормально через
openocd -f board.cfg -c "program xxxx.elf"(это приблизительно). Дальше всё работает.
Вердикт. Полез читать, оказалось JLink из ST-LInk совсем не J-Link, а подобие, и выходит что openocd с ним криво работает. Откатился к ST-link. Всё работает.
ЗЫ. А вот Keil под виндой с этим JLink'ом давал жару на 50 МГц, вливая код за мгновения. И точек останова больше (неограничено типа, в st-link 6) и скорость хорошая.
Это тоже Cortex M4, потому рецепты те же, что в статье. Единственное, Qbs не осилил, остановился на сmake, благо Creator с ним тоже прекрасно работает.
Аналогичным образом добавляем отладчик arm-none-eabi-gdb
стоит отметить, что в данный момент, если GDB старше какой-то версии, то отладка не запускается. GDB 8.0 — не работает. GDB 7.7.1 — работает. Естественно оба с поддержкой Python.
Вопрос: В какой момент и каким образом происходит заливка прошивки?
Настроил QtCreator и openocd по Вашей инструкции (и перепроверил на нескольких аналогичных), собрал проект, но я не вижу что либо в логах похожее на заливку. В итоге дебаг не идет толком, иногда стопается в рандомных точках в ассемблере, но в мейн так и не попал. Проект — простейшая моргалка. Пробовал 3 разные платы на stm32f103cb, stm32f407ve и stm32f407vg. последняя — честный Discovery с настоящим st-link-ом. Остальные пытаюсь скрестить с китайским двухбаксовым клоном
Заливка происходит командой load. Ее видно в окне настройки gdb сервера.
Но основной затык был в том, что контроллер не переходил в режим программирования (или неправильно ресетился — не знаю). Я пытался запустить это в связке с openocd 0.10. После долгого гуглежа оказалось нужно добавить команду «monitor reset_config none separate» перед ресетом перед заливкой прошивки. В моем случае список команд для gdb сервера выглядит так (я добавил только одну, остальные там были по умолчанию)
set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4
monitor reset_config none separate
monitor reset halt
load
monitor reset halt
Вдруг кому пригодиться
Разработка велась в среде IAR, и многие согласятся со мной, что по сравнению с разработкой в QtCreator'е это боль и страдание.
Да. IAR отстой. Он ещё перетирает изменение файлов, которые сделаны текстовыми редакторами извне IAR.
Программируем микроконтроллеры stm32 при помощи QtCreator