Jump to content

    

rsrg

Участник
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Обычный
  1. Выяснилась интересная особенность: проблема повторяется и на другом компьютере и не связана с софтом J-Link 7.50. Если подключать J-Link к ПК напрямую, без USB хаба, то J-Link "отваливается" (переходит в бутлоадер и не определяется виндой, как писал выше). Но если включить через USB хаб, то определяется и работает. Пробовал и хабы USB2.0 и USB3.0, значения не имеет - работает с обоими. На рабочем ПК, на котором впервые обнаружил проблему, тоже работает через хаб. Осталось только добиться чтобы работал с ARM9.
  2. Не стоит, я уже пожалел, что взял. Работает только с крякнутым софтом который прислал продавец, т.е. ни каких обновлений пока не предвидится. Из имеющихся у меня контроллеров, работает только с Cortex-M, c ARM9 не работает. Если нужен именно V11, то лучше взять EDU.
  3. Вернул ту прошивку, которая в патченной JLinkARM.dll присланной продавцом. Попробовал подключиться к STM32 по JTAG - работает. С CC1352R1 по сJTAG тоже работает. C ARM9 работать оказывается. Писал продавцу, он делает вид что не понимает о чем идет речь. Кто пробовал клоны V11 с ARM9, напишите, пожалуйста, работают ли они с этими ядрами или только Cortex-M.
  4. Пробовал с JLink_V632h. Строку "V11 compiled" найти не смог, есть только строки "V10 compiled". Заменил дату в трех местах V10 на V11, после этого J-Link прошился. J-Link Commander стал показывает Hardware version: V10.10 По прежнему выдает сообщение "defective" К Cortex-M по SWD подключается, к ARM9 по JTAG не подключается.
  5. Извините, наверное я слишком сумбурно описал ситуацию. Да действительно складывается впечатление, что он переходит в режим бутлоадера, но это происходит не сразу после подключения к ПК, а через какой-то промежуток времени от 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 год и решил, что версия понизилась. Спасибо за совет, сейчас буду пробовать
  6. Понятно, а я уже губу раскатал )) Еще возникла такая проблема: после подключения к ПК с установленным софтом 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 вплоть до самой последней. Может кто сталкивался с подобным и подскажет что можно сделать.
  7. У меня тоже китайский J-Link V11. С оригинальным софтом работать отказывается. Можно ли его допилить описанным выше способом?
  8. Доброго времени суток! Пытаюсь запустить 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. Подскажите, пожалуйста куда копать.