Search the Community

Приветствую участников форума, Пробовал-ли кто-нибудь заставить работать Gowin Analyzer Oscilloscope с Tang Nano 9K или каким-либо другим нестандартным кабелем USB<=>JTAG? На плате Tang Nano стоит не родной преобразователь, а его эмуляция на BL702: Bus 001 Device 009: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6010 FT2232C/D/H Dual UART/FIFO IC bcdDevice 5.00 iManufacturer 1 SIPEED iProduct 2 JTAG Debugger iSerial 3 FactoryAIOT Pro bNumConfigurations 1 Через openFPGALoader плата определяется и программируется, т.е. сам по себе преобразователь рабочий. Но среды Gowin Programmer и Gowin Analyzer Oscilloscope его признавать не хотят. Судя по онлайн-помощи из утилиты programmer_cli поддерживается несколько вариантов кабелей: --cable "Gowin USB Cable(FT2CH)" Select a type of USB cable(including quotation marks): "Gowin USB Cable(GWU2X)" "Gowin USB Cable(FT2CH)" "Parallel Port(LPT)" "Digilent USB Device" "USB Debugger A" Default cable is "Gowin USB Cable(FT2CH)" --cable-index <int> Select a number for USB cable: 0: Gowin USB Cable(GWU2X); 1: Gowin USB Cable(FT2CH); 2: Parallel Port(LPT); 3: Digilent USB Device; 4: USB Debugger A; Higher priority than --cable, default cable-index is 0 Но перебор их ничего не дал, т.к. в лучшем случае я получаю сообщение "Unknown Cable" и дальше дело не идёт. Есть какие-нибудь варианты заставить работать Gowin Analyzer Oscilloscope с нестандартными кабелями?

Здравствуйте. Кто-нибудь делал для Gowin обновление конфигурации по JTAG с микроконтроллера ? Что-то описание у них мутное какое-то. В описании одно пишут. Создал SVF файл - так как-то иначе все выходит. У меня пока что получилось только ID и регистр статуса прочитать. Теперь бьюсь со стиранием - никак не выходит.

Доброго всем времени суток! При реализации механизма программирования внутренней флеш-памяти ПЛИС GW1N-9C через JTAG на GPIO МК внезапно выяснилось, что данные в Y-страницы флеш-памяти (4 байта) необходимо писать в перевёрнутом виде, т.е. младший по смешению из bin-файла байт (например, по смещению 0) пишется по смещению старшего байта (т.е. по смещению 3) и так далее. При этом, что интересно, в генерируемом средой Gowin Programmer SVF-файле этого переворота нет, судя по моим наблюдениям. Соответственно если использовать SVF без модификаций, то КМК прошить им ПЛИС не получится. Может быть кто-то пробовал и готов поделиться результатом? В документации от Gowin на этот счёт путаница: они пишут про программирование Y-страницы начиная с LSB, говоря о битах, но на самом деле LSB - это младший байт. При этом в проекте openFPGALoader (файл src/gowin.cpp) также присутствует переворот (tx[3-x] = t[x]), что подтверждает мою гипотезу: for (int ypage = 0; ypage < nb_iter; ypage++) { unsigned char *t = buffer+xoffset + 4*ypage; for (int x=0; x < 4; x++) { if (page == 0) tx[3-x] = t[x]; else tx[x] = t[x]; } _jtag->shiftDR(tx, NULL, 32); if (!is_gw1n1) _jtag->toggleClk(40); } Условие page == 0 соответствует программированию конфигурации ПЛИС. При прошивке пользовательской области флеша переворот байт не выполняется. В любом случае после добавления аналогичного кода перестановки байт в слове Y-страницы прошивка успешно стартовала и ПЛИС работает как было задумано. PS: В руководстве от Gowin процедура верификации внутреннего флеша после программирования также описана некорректно. Для её лучшего понимания советую посмотреть на генерируемый средой SVF-файл.

Добрый день, Дано: Gowin_V1.9.8.08 и programmer_cli из этого набора; Кабель на базе FT2232H, у которого для подключения JTAG задействован канал B. Кабель успешно определяется средой: $ sudo ./programmer_cli --scan-cables Cable found: Gowin USB Cable(FT2CH)/0/5873/null (USB location:5873) Cable found: Gowin USB Cable(FT2CH)/1/5874/null (USB location:5874) Cost 0.11 second(s) При этом все попытки работать со вторым каналом с помощью параметра --channel 1 эффекта не дают, хотя по описанию и по выдаче выбирается именно второй канал - B (немного смущает надпись null на конце выдачи в имени кабеля): $ sudo ./programmer_cli --channel 1 --scan Scanning! Target Cable: Gowin USB Cable(FT2CH)/1/0/[email protected] Error: No Gowin devices found! Cost 0.54 second(s) При этом если выбирать порт кабеля с помощью параметра --location 5874, то сканирование успешно выполняется и программатор работает как обычно (несмотря на совершенно кривую выдачу): $ sudo ./programmer_cli --location 5874 --scan Scanning! Target Cable: Gowin USB Cable(FT2CH)/0/0/[email protected] Device Info: Family: GW1NR Name: GW1N-9C GW1NR-9C (One of them) ID: 0x1100481B 1 device(s) found! Cost 1.04 second(s) Я что-то упускаю при использовании параметра --channel 1? Или это всё-таки проблема (ошибка) программатора? PS: Перейти на использование канала A сейчас возможности нет. PPS: Проблем бы не было, если бы не постоянно мутирующие значения location, которые ожидаемым образом изменяются от подключения к подключению кабеля, что доставляет массу неудобств.

Имею на руках означенный родной программатор. Вопрос: его работоспособность можно как-нибудь проверить, не имея на руках (пока) ничего, роме как кита DK_START_GW2AR-LV18EQ144PC8I7_V1.1, которому внешний программатор как собаке пятая нога, т.к. имеется такой же на борту? Смысл пробы - сотворить простейший переходник с него на эфовский (начало не помню, но оканчивается на Iso) от @StewartLittle под разводку последнего, дабы к приходу смонтированных плат хоть один вариант того, что не прошивается (ежели таковой казус и произойдёт), был бы мог смело быть отметённым.

Добрый день, есть убунта 20.04, на ней успешно стоит GoWin EDA и успешно все собирает. Сделал свой первый проект под GoWin, и пытаюсь загрузить. Похоже загрузчик не видит порт. Пробовал под рутом, и без рута. Ничего не получается. На том же компе у меня успешно под ардуиной грузится все, что можно. При втыкании борды в усб наблюдаю и в /dev появляются ttyUSB0 и ttyUSB1, но после запуска загрузчика (хоть с командной строки, хоть с оболочки) они оттуда исчезают. С командной строки пробовал даже так: в этом случае, программатор уже не ругается, что не видит порт, но пишет, что де PS: винды нет, и ставить некуда, так как привык работать на лаптопе с этой убунтой. Пожалуйста, подскажите, что попробовать, чтобы все-таки запустить это все? Спасибо! ИИВ

Доброго дня. Собственно вопрос в том, что хочу по аналогии с брендами иметь встроенный отладчик на разрабатываемой своей отладке. Сам пользуюсь всякими, целевая плата на мк от Миландра (ВК018 - 2xCM4F+1xCM0) . Посмотрел я на весь зоопарк и подумал, что вроде бы возможно совместить в одной схеме на F103C8 четыре типа: JLINK OB, STLINK V2, CMSIS-DAP и BMP. Первые три я использовал для Миландра, последний пока нет. У каждого из них есть достоинства и недостатки. Обычно я использую JLINK OB, но через год текущая конфигурация ПО может не заработать. Поэтому хочу заложить степени свободы. У меня есть и покупные JLink'и, но они "гуляют по рукам". Хочу, чтобы отладчик всегда был при плате. В общем, если бы вы делали отладку для себя и закладывали туда встроенный отладчик, то какой бы вариант использовали, исходя из практического опыта их применения? Может быть уже существует универсальная надёжная схема такого устройства? Я сам планирую совместить все схемы указанных выше отладчиков и менять на них прошивки по необходимости. К примеру, если под задачу изменился комплект среды и компилятора. Либо человек, использующий отладку, привык к конкретному набору окружения разработчика.

Коллеги, добрый день Продам отладчик для ПЛИС Xilinx. Состояние нового. В оригинальной коробке со всеми документами и проводами. 8 500 р. Самовывоз в Москве, отправка в регионы.

Компания Xilinx добавила продукт в свой портфель модулей программирования, отладки и трассировки модуль SmartLynq+. Это высокоскоростной модуль отладки и трассировки, в первую очередь ориентированный на проекты, использующие платформу Versal, который значительно улучшает процесс конфигурации и скорость трассировки. Модуль SmartLynq+ обеспечивает до 28 раз более быстрое время загрузки Linux через высокоскоростной порт отладки (HSDP), чем через кабель передачи данных SmartLynq. Для захвата трассировки модуль SmartLynq+ поддерживает скорость до 10 Гбит/с через интерфейс HSDP. Это в 100 раз быстрее, чем стандартный JTAG. Более быстрые итерации и повторяющиеся загрузки повышают продуктивность разработки и сокращают цикл проектирования. Это означает снижение времени, затраченного на отладку, вместо которой вы можете сосредоточиться на запуске своих решений на основе Versal. Узнать больше

Доброго времени суток. Есть FPGA плата с установленным USB-JTAG bridge device (как, кстати, будет корректно обозвать его по-русски?), на которую периодически требуется удалённо заливать новую версию прошивки. Инструкция предусматривает отключение USB кабеля после записи прошивки в конфигурационную память. Первое, что пришло в голову - это удалённо управляемый USB контроллер или коммутатор, но те, что мне удалось найти, служат для управляемой коммутации нескольких USB соединений. Посоветуйте, как можно решить задачу удалённого отключения/подключения USB?

Документ содержит руководство по установке OpenOCD для ESP32 и отладке с использованием GDB в Linux, Windows и MacOS. В Руководстве также представлены примеры отладки, предоставленные как для Eclipse, так и для Командной Строки, дана подборка советов и рассмотрены особенности, связанные с отладкой JTAG ESP32 с OpenOCD и GDB. Подробнее>>