Проблемы проявлялись так: программатор иногда молчал порядка 30 секунд и выдавал «JTAG chain broken», а в Wireshark исходящий USB-трафик выглядел испорченным ещё до того, как данные доходили до FT245 или CPLD. Пару лет назад автор бросил разбираться, а теперь передал обе задачи Claude Opus 5.5, который занялся реверс-инжинирингом jtagd. По словам автора, модель иногда упиралась в ограничения по кибербезопасности, но лучше прежних версий пробовала другой подход и давала переформулировать запрос.
Первый баг — неинициализированная переменная в конструкторе JTAG_SERVER_USB_BLASTER. Конструктор обнуляет набор соседних переменных, а эту, судя по всему, забыли; если в ней оказывается значение больше 0, в исходящий поток попадают данные протокола более нового USB-Blaster II, и старые клоны это ломает. По наблюдениям автора, такое случается, если отключить и снова подключить программатор, не останавливая jtagd: при горячем подключении создаётся новый объект, а участки кучи переиспользуются.
Второй баг связан с порядком команд, которые jtagd отправляет чипу FT245 при первом открытии: Reset, Purge TX, Purge RX, Set Latency Timer. Такая последовательность, по данным автора, заставляет некоторые клоны примерно на 250 мс перестать принимать входящие данные, а jtagd в этот момент уже опрашивает устройство и застревает на 30 секунд в ожидании ответа. Если поставить Set Latency Timer первой, проблема исчезает; разные клоны реагируют по-разному, что автор связывает с возможными различиями в ревизиях чипа.
Обе проблемы присутствуют в jtagd как минимум с Quartus 18.1 и сохраняются в Quartus 25.1. Автор опубликовал патчер для jtagd на GitHub и просит Altera исправить хотя бы первый баг, тогда как насчёт второго не уверен, что это вообще баг.
Почему это важно
Для команд, которые ведут разработку на FPGA и используют недорогие клоны USB Blaster в Linux, такие зависания превращаются в потерю времени на диагностику плавающих сбоев и в ложные подозрения на железо. Патчер даёт временное решение без ожидания обновлений Quartus, а сам кейс показывает, как ИИ ускоряет разбор закрытых утилит вендора. Для бизнеса это напоминание: сбойное ПО программатора может тормозить весь цикл отладки, поэтому стоит фиксировать версии инструментов и проверять воспроизводимость проблем на конкретных конфигурациях.
Источник: Habr. Материал пересказан ИИ-агентом.
