LINUX.ORG.RU

ARM semihosting

 , , , ,


0

2

Тыкаю STM32, пытаюсь заставить нормально работать semihosting. У меня есть STM32F103C8T6, китайский ST-LINK/V2 (SWD), GNU Arm Embedded Toolchain, openocd и stlink.

Хочу, чтобы при выполнении make debug запускался gdb, подключался к отлаживаемому контроллеру и по continue начинал выполнение программы, выводя все сообщения из printf.

Вариант первый: запускаю st-util --semihosting, в gdb выполняю: target extended-remote localhost:4242, load, monitor semihosting enable, continue. Вывод printf попадает не на терминал gdb, а в файл с именем ":tt".

Вариант второй: запускаю openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg, в gdb выполняю: target extended-remote localhost:3333, load, monitor arm semihosting enable, continue. Вывод printf попадает в терминал openocd, а не в терминал gdb, что уже лучше, но все равно не так удобно.

Другие варианты: собрать JTAG-отладчик на коленке, модифицировать прошивку китайского ST-LINK/V2, чтобы gdb-server крутился прямо на нем и openocd с stlink стали не нужны (не рассматриваются из-за нетривиальности).

Поясните, как вы это настроили для себя и реально ли вообще добиться, чего я хочу, без патчей на openocd/stlink? cast Vit, ncrmnt, Eddy_Em

Для желающих потыкать, выкладываю полный исходный код:

#include <libopencm3/stm32/rcc.h>
#include <stdio.h>

/* For semihosting on newlib */
extern void initialise_monitor_handles(void);

static void clock_setup(void) {
	rcc_clock_setup_in_hse_8mhz_out_72mhz();
}

int main(void) {
	clock_setup();
#if defined(ENABLE_SEMIHOSTING) && (ENABLE_SEMIHOSTING)
	initialise_monitor_handles();
#endif

	printf("Hello World\n");

	/* Wait forever and do nothing. */
	while (1)
		__asm__("nop");

	return 0;
}
BINARY = test

OPENCM3_DIR = ../libopencm3
LDSCRIPT = $(OPENCM3_DIR)/lib/stm32/f1/stm32f103x8.ld

# To disable, run "make ENABLE_SEMIHOSTING=0" or comment next line out
ENABLE_SEMIHOSTING ?= 1

ifeq ($(ENABLE_SEMIHOSTING),1)
LDFLAGS		+= --specs=rdimon.specs
LDLIBS		+= -lrdimon
DEFS		+= -DENABLE_SEMIHOSTING=1
endif

include ../libopencm3.target.mk

★★★★★

меня конечно не приглашали, но почему бы шкворца не набить :)

чем не устраивает printf в uart? Я конечно понимаю про экономию на uart-usb. Но как мне кажется это удобней и имеет более широкие возможности по отладке.

yax123 ★★★★★
()
Ответ на: комментарий от SL_RU

SWO удобнее semihosting'а

Верю, но я хочу принципиально semihosting.

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от yax123

чем не устраивает printf в uart?

Сейчас использую именно USB-UART, перетыкать каждый раз неудобно. До этого использовал st-term, но теперь его выкинули из stlink в пользу semihosting.

CYB3R ★★★★★
() автор топика

Меня по подобным вещам не надо звать (да и вообще не надо, т.к. я под своим ником уже много лет не хожу). gdb не использую, как и JTAG/SWD. Считаю это извращением (я о JTAG/SWD), когда есть бутлодырь. Шью или через UART1, или через USB.

// Eddy_Em

anonymous
()
Ответ на: комментарий от anonymous

И да, тебя не напрягает, что разрабы opencm3 периодически API ломают?

Меня это напрягает, как и собственно разбазаривание попусту ресурсов МК. Перешел на «чистый» CMSIS. Доволен.

anonymous
()
Ответ на: комментарий от anonymous

разбазаривание попусту ресурсов

Нормальная штука для ознакомления и быстрого получения каких-то результатов. Всему своё место.

anonymous
()

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

Vit ★★★★★
()
Ответ на: комментарий от CYB3R

Сейчас использую именно USB-UART, перетыкать каждый раз неудобно.

а что значит перетыкать? у тебя всего один usb-порт в компе? У тебя настолько мелкий контроллер что все сидит на одних и тех же ногах?

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Я везде eddy_em, а досикус — ярый вантузятник, он на ЛОР не ходит.

anonymous
()
Ответ на: комментарий от yax123

Вот тоже не понимаю, что он там перетыкает: я подключаю на UART1 конвертер в USB, через него шью, жамкаю reset и отлаживаю.

Разве что неудобно то, что для прошивки надо кнопки boot и reset жать, а после окончания прошивки опять reset давить. Шить через usb-dfu очень медленно (да и тоже кнопки жать надо)...

anonymous
()
Ответ на: комментарий от anonymous

Разве что неудобно то, что для прошивки надо кнопки boot и reset жать

жесть-то тракторная какая!

А что мешает прицепить SWD, uart-usb, логический анализатор и вообще руки с клавиатуры не убирать? При том что все это ну реально «копейки» стоит.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

что мешает прицепить SWD

Занимать ценные ноги всякой гадостью? Нет уж, спасибки!

Да и нахрен мне столько навешивать внешней дряни, если можно прошивать через все равно подключенный для отладки usb<->ttl?

Вот бы еще освоить написание самопального бутлодыря, чтобы кнопки жамкать не надо было... Да и удобно было бы прошивать МК удаленно (через USB или CAN).

anonymous
()
Ответ на: комментарий от yax123

Несколько контроллеров, перетыкать приходится USB-UART, вместе с программатором. Программатор — 4 провода, а UART еще 3.

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от CYB3R

Современные STM'ки с аппаратным USB можно шить через USB-DFU, правда, это жутко медленно!

anonymous
()
Ответ на: комментарий от CYB3R

Несколько контроллеров, перетыкать приходится USB-UART, вместе с программатором. Программатор — 4 провода, а UART еще 3.

Экономию на спичках вижу тут.
Что мешает сделать один 7 контактный разъем через который и подключать программатор и уарт?
Что мешает купить длинную PLS, нарезать по 8 контактов, припаять на провода каждой плате и втыкать в нее BLS-8 к которой припаяны программатор и уарт-усб?
Что мешает купить 10 программаторов и 10 уарт-усб и большой усб-хаб и вообще ничего не перетыкать?

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Если бы все STM32 имели на борту USB, и прошивка через DFU не занимала бы столько времени, я вообще не пользовался бы переходниками UART<->USB, т.к. и прошивку, и отладку можно было бы делать через USB! Это вообще идеально было бы: никаких лишних ног занимать не надо! Разве что все равно приходится жамкать кнопки reset и boot. Чтобы совсем хорошо было, надо писать свой бутлоадер. А лень.

anonymous
()
Ответ на: комментарий от anonymous

никаких лишних ног занимать не надо!

не оправдывайся экономщик :))))

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

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Это как, интересно, я сэкономлю время, если вместо отладки через CDC или UART буду отлаживать через SWD? Наоборот, больше секса будет с чертовым gdb! Да и нахрен мне это пошаговое выполнение? Издевательство сплошное!

Лучше мигания светодиодом, осциллографа и логанализатора, а также отладочных сообщений в терминал еще ничего не придумали!

anonymous
()
Ответ на: комментарий от yax123

Ну вот лично мне не нравится такое отношение «и так сойдет», если можно использовать semihosting, почему бы этого не делать?

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от CYB3R

если можно использовать semihosting, почему бы этого не делать

А я где-то сказал, что семихостинг это плохо? вовсе нет. Тут только вопрос на, что тратить время. На мой взгляд, если не взлетело с первого тычка, то можно послать нафиг. Не настолько критичный инструмент.

yax123 ★★★★★
()
Ответ на: комментарий от anonymous

Это как, интересно, я сэкономлю время

Обожаю лорчик :)))))
Сначала выдумаем несуществующую факт, а потом будем его усиленно опровергать.

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

С другой стороны если вы кроме пошагового выполнения больше ничего в gdb не можете, то это скорей плохо, чем хорошо. Удобно поставить брейкпоинт, и потом посмотреть окружение. Удобно поставить условный брейкпоинт и посмотреть окружение. И это удобней и быстрей чем фигачать printf на переменную, потом убедится, что она не причем, добавить следующую (дописать код, компельнуть, прошить, перезапустить) и вот уже набегают минуты и часы отладки.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

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

anonymous
()
Ответ на: комментарий от anonymous

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

Я же уже рассказал в каких реальных случаях это может быть выгодней по времени. Когда знаешь где остановиться и знаешь список того на, что нужно глянуть и вот чтобы не писать вывод в консоль значений этого списка удобен gdb. А в случае отладки МК нужен еще gdb-server. И вот тут-то у железячников совсем крышу сносит :).
Негодные железячники, гоните их, насмехайтесь над ними :)

yax123 ★★★★★
()
Ответ на: комментарий от anonymous

а взять тот же мэпловский религия не позволяет? :)

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

угу, и нормальное IDE не осилили, которое позволяет посмотреть и переменные, и память, и все прочее по брейкпоинту в нужной точке... хоть эклипс, хоть Qt creator...

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

Что за «мэпловский»?

maple bootloader

А нормальное IDE я осилил — Geany. Эклипса и культекреатор — говно жирное.

ну и корячьтесь дальше с помаргиванияи-попукиваниями в такт, дело ваше :) кому и блокнот - IDE...

NiTr0 ★★★★★
()
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от anonymous

какая ардуина, ау??? онанимус упоролся?

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

А нормальное IDE я осилил — Geany.

Всем известно, что нормальное иде это vim

Но если пограмист не умеет писать и отлаживаться без эклипса и кутекриейтора, то он ущербен по определению. Тем не менее это не освобождает от знаний и умений gdb+openocd.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Всем известно, что нормальное иде это vim

Это — худшее, что можно придумать. mceditor и то юзабельней…

Ты бы еще Emacs вспомнил.

anonymous
()
Ответ на: комментарий от anonymous

Это — худшее, что можно придумать. mceditor и то юзабельней…
Ты бы еще Emacs вспомнил.

вот и нет у нас Архыза :)))))))

А если серьезно, потрать время на изучение.

yax123 ★★★★★
()
Ответ на: комментарий от yax123

Удваиваю про гдб и опеноцд: без них не смогли бы отдебажить и найти багу в свежем силиконе, тк расстановка принтов меняла лейаут кода и ошибка, которая до этого воспроизводилась 1 раз из 100 запусков, воспроизводиться переставала.

Deleted
()
Ответ на: комментарий от yax123

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

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

А вообще, в реальности это бывает нужно крайне редко, и внимательное чтение RM с errata + вникание в то, что ты сам написал, помогает основную массу ошибок исправить. Потому как не может быть такого, чтобы ты регистр изменял, а он не изменялся. Или запустил таймер, а он не работает...

По сути, отладка кода — это выражение собственной лени: лень читать документацию, хочется с наскока решить проблему. А бац — забыл какой-нибудь регистр изменить...

anonymous
()
Ответ на: комментарий от NiTr0

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

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

yax123 ★★★★★
()
Ответ на: комментарий от anonymous

Пока что это сделано через одно место.

тыкнуть в IDE возле строчки и получить брейкпоинт - «через одно место»?

ах да, я забыл - вы же пользуете линукс-аналог продвинутого notepad-а вместо IDE...

А вообще, в реальности это бывает нужно крайне редко, и внимательное чтение RM с errata + вникание в то, что ты сам написал, помогает основную массу ошибок исправить. Потому как не может быть такого, чтобы ты регистр изменял, а он не изменялся. Или запустил таймер, а он не работает...

ну если «в реальности» писать моргалки светодиодом - то да, там отладка не нужна.

а когда есть куча асинхронных функций, общающихся друг с другом, а общий объем кода подбирается к 50 кб с -Os - тут другой разговор...

NiTr0 ★★★★★
()
Ответ на: комментарий от yax123

Это нужно только тогда когда пишешь код не приходя в сознание, а потом уже на свежую голову нужно понять, что происходит (так как в коде сплошная хрень и лапша).

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

А некоторые вещи вообще невозможно по-шагово отлаживать, например взаимодействие с внешним миром (никто не будет ждать пока ты там все эти шаги рассмотришь).

вполне себе отлаживается. ткнул брейкпоинт в интересущем месте и посмотрел, почему же падает/работает не так как ожидалось.

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

а когда есть куча асинхронных функций, общающихся друг с другом

То брекпойнты не помогут никак! Подгадывать, что ли, момент, когда сработает прерывание? Или на лету менять регистры??

Чушь все это. От такой отладки практической пользы ровно 0. Если в голове пустота, то она поможет, потому что код - говно! Нет сигнала в шине — значит забыл какой-то флаг выставить. И внимательное прочтение своего кода этому поможет.

И не надо мне про IDE! Эклипса и культекриатор — говно, а не IDE!!1

anonymous
()
Ответ на: комментарий от NiTr0

да-да, брейкпоинты на интересующих строках и отображение в реалтайме любых переменных - не нужны

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

yax123 ★★★★★
()
Ответ на: комментарий от anonymous

То брекпойнты не помогут никак!

может онанимус научился бы пользоваться головой при отладке? :)

Подгадывать, что ли, момент, когда сработает прерывание?

можно и в прерывании поставить, и условный - если прерывание сменило флаг в переменной.

Или на лету менять регистры??

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

И не надо мне про IDE! Эклипса и культекриатор — говно, а не IDE!!1

да-да, мнение онанимуса, не отличающего IDE от тупого редактора с подсветкой синтаксиса, весьма ценно и важно, да...

NiTr0 ★★★★★
()
Ответ на: комментарий от yax123

да, я сразу тыцаю пимпочку «билд», и через секунду после окончания билда у меня прошивка уже в девайсе. и как только я вижу ошибочное поведение - я тыцаю на строчке, где предположительно оно вылазит, и уже прекрасно видно почему оно вылезло. со ВСЕМИ глобальными и локальными переменными вместо куцого огрызка printf, с возможностью изменить их значение на произвольное, и т.п.

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

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

NiTr0 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.