Работа с контроллером через JTAG

назад

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

Железо (и кулстори)

Есть такая серия микросхем ft232 - переходник USB-UART. В принципе, уже этого достаточно для программирования через bootloader. Но помимо просто переходника, эти микросхемы умеют программно дрыгать ногами по командам с компьютера, этот режим называется bitbang. Проблема в том, что у стареньких ft232rl этот режим реализован как-то неудачно, из-за чего работа с JTAG идет со скоростью считанные байты в секунду. Но есть более современная серия ft232h. Причем это именно серия: помимо одиночного ft232h есть еще ft2232h и ft4232h, сдвоенный и счетверенный соответственно. То есть в одной микросхеме как будто 4 переходника! Правда, у них неприятный корпус (LQFP64 - целых 64 вывода с шагом 0.5мм), да и обвязка посложнее. Разумеется, такие микросхемы продаются не только сами по себе, но и запаянными в готовые платы… но мы ведь не ищем легких путей!

Счетверенную микросхему я посчитал избыточной, да и конфиг-файлов под нее сложно найти, поэтому заказал ft2232h, изготовил под нее плату (схема целиком из даташита, поэтому приводить здесь не буду) и запаял. Однако при подключении к компьютеру оказалось, что микросхему мне продали фальшивую: она определилась как ft4232h. То есть кто-то решил перемаркировать более функциональную микросхему под менее функциональную. Зачем - непонятно. Для меня это с одной стороны хорошо: больше возможностей как-никак, но с другой плохо: плату-то я под другую делал, там и маркировка не так, и расположение выводов, да и конфиг-файлы искать придется. Впрочем, ничего страшного, превозмогать так превозмогать.

Конфиг-файлы и порядок проводочков

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

Номер вывода	Назначение	JTAG
16 / 26 / 38 / 48	D0 / Tx	TCK
17 / 27 / 39 / 52	D1 / Rx	TDI
18 / 28 / 40 / 53	D2 / RTS	TDO
19 / 29 / 41 / 54	D3 / CTS	TMS
21 / 30 / 43 / 55	D4 / DTR	JRST	не обязательный
	D5 / DSR
23 / 33 / 45 / 58	D6 / DCD	RST
	D7 / RI

Не забываем про питание и, особенно, землю!

Ну и конфиг-файл для openocd:

adapter driver ftdi
ftdi_vid_pid 0x0403 0x6011
ftdi_channel 1
ftdi_layout_init 0x0030 0x003b
ftdi_layout_signal nSRST -data 0x0010 -oe 0x0010
ftdi_layout_signal nTRST -data 0x0020 -oe 0x0020
adapter speed 1000

Кроме того, ft’шка умеет работать не только по JTAG, но и по SWD - другому отладочному интерфейсу. Не уверен, что GD32VF103 его поймет, но для полноты картины приведу и эту конфигурацию. Обратите внимание на резистор 510 Ом между D1 (Rx) и D2 (RTS). Из общих соображений я предполагаю, что его номинал можно увеличить килоом да 10.

D0/Tx--------------------SWDCLK / TCK
D1/Rx-----[510]----┐
D2/RTS-------------+-----SWDIO / TMS

Конфиг-файл:

adapter driver ftdi
ftdi_vid_pid 0x0403 0x6011
ftdi_channel 1
ftdi_layout_init 0x0030 0x003b
ftdi_layout_signal SWD_EN -data 0
adapter speed 1000
transport select swd

В конфиг-файлах следует обратить внимание на строчку ftdi_vid_pid: для других, чем у меня, микросхем, надо пару vid:pid узнать (да хотя бы из lsusb) и вписать сюда

Вторая важная вещь - ftdi_channel, который у меня выставлен в 1. Дело в том, что плата разводилась под сдвоенный переходник, а достался счетверенный. Поэтому подписи выводов совпали только для нулевого (A) и частично второго (C) канала. А первый и третий остались A0-A7, вот их я и использую для альтернативных применений, а 0 и 2 по прямому назначению, как переходники на UART. Так что если вам удобнее повесить JTAG или SWD на другой канал, не забульте поменять

Софт

Для программирования (и, возможно, отладки, хотя ее я не щупал) используется OpenOCD (open on-chip debugger). С ним проблема в том, что тот, который идет в репозитории, скорее всего не понимает RISC-V. Поэтому придется собирать из исходников. Вот отсюда https://github.com/riscv/riscv-openocd.

Вторая проблема - подобрать правильное заклинание для прошивки. С этим проще: подошло заклинание от stm32:

openocd -f ft4232.cfg -f gd32vf103.cfg -c "init" -c "reset halt" -c "flash write_image erase firmware.bin 0x08000000" -c "reset run" -c "exit"

Найти эти файлы можно тут: ft4232.cfg, ft4232_swd.cfg, gd32vf103.cfg

Заключение

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

Но если кто-то данным контроллером заинтересуется - потенциально возможность внутрисхемной отладки крайне полезна.