rsrg

I also have JetLink SuperPro (J-Link hardware V3. 0). This probe work only with old driver versions. New driver versions report "defective".

I have Jetalink Ultra+ V4. It works with the latest driver version v7.52b (x64) and latest firmware Jul 28 2021

В общем, разобрался почему мой клон V11 не работал с ARM9, проблема оказалась в самом ARM9, а в отладочной плате на которой выполнялась проверка. GPIO контроллера, на котором линия TMS, может быть сконфигурирован как UART_RX и на отладочной плате установлены драйвера RS-232 и RS-485. Так вот выход RS-232 был подключен (джампером) к линии TMS. В свою очередь на китайской версии J-Link V11 резисторы включенные последовательно с линиями JTAG имеют номинал 220 Ом, а на JetLink V4 - 100 Ом. Номинала 100 Ом хватало, чтобы установить линию TMS в состояние логического "0", а 220 Ом уже не достаточно. В общем с ARM9 тоже работает, а то я уже начал думать, что китайцы прислали J-Link с прошивкой от какой нибудь версии OB.

Напишите, пожалуйста, какие ошибки в схеме были у Вас. Пробовали отлаживать, что нибудь отличное от Cortex-M по JTAG работает ли это? Мой клон V11 работает по SWD c Cortex-M, но не работает по JTAG с ARM9. Проблема возникает на стадии подключения и сканирования цепочки TAP. - Could not measure total IR len. TDO is constant high Посмотрел логическим анализатором - действительно TDO постоянно в уровне логической 1. Но при этом TMS тоже всегда высокий, увидел на нем только короткие иголки длительностью 16 нс. Хотелось бы понять аппаратная ли это проблема и где её искать. Подключение J-Link V11: Для сравнение подключение через J-Link Ultra V4: Подскажите, пожалуйста, есть ли команда позволяющая вручную устанавливать состояние линии TMS?

Выяснилась интересная особенность: проблема повторяется и на другом компьютере и не связана с софтом J-Link 7.50. Если подключать J-Link к ПК напрямую, без USB хаба, то J-Link "отваливается" (переходит в бутлоадер и не определяется виндой, как писал выше). Но если включить через USB хаб, то определяется и работает. Пробовал и хабы USB2.0 и USB3.0, значения не имеет - работает с обоими. На рабочем ПК, на котором впервые обнаружил проблему, тоже работает через хаб. Осталось только добиться чтобы работал с ARM9.

Не стоит, я уже пожалел, что взял. Работает только с крякнутым софтом который прислал продавец, т.е. ни каких обновлений пока не предвидится. Из имеющихся у меня контроллеров, работает только с Cortex-M, c ARM9 не работает. Если нужен именно V11, то лучше взять EDU.

Вернул ту прошивку, которая в патченной JLinkARM.dll присланной продавцом. Попробовал подключиться к STM32 по JTAG - работает. С CC1352R1 по сJTAG тоже работает. C ARM9 работать оказывается. Писал продавцу, он делает вид что не понимает о чем идет речь. Кто пробовал клоны V11 с ARM9, напишите, пожалуйста, работают ли они с этими ядрами или только Cortex-M.

Пробовал с JLink_V632h. Строку "V11 compiled" найти не смог, есть только строки "V10 compiled". Заменил дату в трех местах V10 на V11, после этого J-Link прошился. J-Link Commander стал показывает Hardware version: V10.10 По прежнему выдает сообщение "defective" К Cortex-M по SWD подключается, к ARM9 по JTAG не подключается.

Извините, наверное я слишком сумбурно описал ситуацию. Да действительно складывается впечатление, что он переходит в режим бутлоадера, но это происходит не сразу после подключения к ПК, а через какой-то промежуток времени от 0,5 до 20 (может и больше) секунд. Это происходит даже если ни какой софт из пакета J-Link не запускать. При этом винда не может поставить на него ни какие драйвера, в диспетчере устройств он отображается как Unknown Device у которого в свойствах отсутствуют VID/PID. Т.е. USB у него вообще не работает. J-Link Commander его не видит. Повторюсь, все это происходит только на компе, на котором ранее был установлен J-Link V7.50. Он действительно работает на других компах, проверял у двух коллег и на домашнем компе. да ругается если не патчить dll, после применения кряка, присланного продавцом, перестал ругаться и коннектится по SWD к STM32F103, пишет и читает flash, но не коннектится по JTAG к ARM9. Это все проверил на домашнем ПК. Таких подробностей не знал. Выполнил команду exec invalidatefw в J-Link Commander. Увидел, что после прошивки дата J-Link V11 compiled изменилась с 2021 на 2020 год и решил, что версия понизилась. Спасибо за совет, сейчас буду пробовать

Понятно, а я уже губу раскатал )) Еще возникла такая проблема: после подключения к ПК с установленным софтом J-Link 7.50 устройство сначала определилось установились драйвера, но при попытке запуска отладки из keil l-link отвалился и вместо него появился Unknown Device. При дальнейших отключения/подключениях j-link к компу в диспетчере устройств на мгновение появляется Jlink driver, тут-же исчезает и появляется Unknown Device. Складывается впечатление, что j-link определяется и по команде драйвера отключает интерфейс USB. Светодиод, при этом, продолжает быстро моргать. Пробовал удалять/переустанавливать драйвера, запускал кряк присланный китайцем, удалял все oem*.inf файлы от seggera c помощью pnputil.exe, ни чего не помогает, как отваливался так и отваливается. При подключении к другому компьютеру с софтом J-Link 6.88 (более новые версии на него ранее не ставились) J-Link корректно определился и я понизил ему версию прошивки. Но на моем ПК он по прежнему не определяется. J-Link V4 Ultra+ на этой же машине определяется и работает нормально с любой версией софта J-Link вплоть до самой последней. Может кто сталкивался с подобным и подскажет что можно сделать.

У меня тоже китайский J-Link V11. С оригинальным софтом работать отказывается. Можно ли его допилить описанным выше способом?

Доброго времени суток! Пытаюсь запустить FreeRTOS на NUC980 на отладочной плате NuMaker-Server-NUC980 (https://www.nuvoton.com/products/iot-solution/iot-platform/numaker-server-nuc980/). В репозитории NUC980_NonOS_BSP есть пример проекта (https://github.com/OpenNuvoton/NUC980_NonOS_BSP/tree/master/SampleCode/FreeRTOS). Проект собранный в Keil запускается и работает без проблем. Стартует и в отладке и при записи на SPI NAND Flash. Проблемы возникли c запуском прошивки собранной с помощью GCC. Если загрузить образ используя NuWriter в ОЗУ, то он стартует и работает нормально, а вот если его записать во Flash, то он стартует и работает до первого отключения питания платы. Если после подачи питания на плату выполнить соединение с NuWriter, при этом ни чего не загружать в контроллер, а просто перевести его в режим загрузки с SPI NAND переключателем на плате и нажать кнопочку reset, то образ, ранее записанный во Flash начинает запускаться нормально (до следующего сброса питания). Так же образ GCC если перед этим запустить любым из доступных способов образ собранный в Keil. Т.е. отличия, скорее всего, заключаются в начальной инициализации. Стартапы Keil и GCC отличаются тем, что для GCC инициализация векторов прерываний и очистка секции bss выполняется в в самом стартапе, а для keil это делается процедурой __main. GCC startup.S: Keil startup.s: При отладке вижу следующее: Запускается Scheduler FreeRTOS и передает управление первой задаче vCheckTask. В этой задаче вызывается vTaskDelayUntil(). Отработав,vTaskDelayUntil() вызывает portYIELD_WITHIN_API() (task.c строка 1275), т.е. `asm volatile ("SWI 0\n"`. Но вместо прерывания по вектору SWI_Handler (vPortYieldProcessor) вызывается прерывание по вектору Undef_Handler. Подскажите, пожалуйста куда копать.