murmur

Добрый вечер, друзья. Не было заботы, да купила баба порося (пардон, не порося, а J-Link) Ранее я заливала прошивку посредством китайского свистка ST-Link, работал он на частоте 1.8 МГц и не более. Тот объем данных для QSPI, который накопился в процессе разработки, заливался минут 40. Был приобретен китайский же J-Link v11. На частоте 15 МГц он прекрасно заливает прошивку во внутреннюю флеш, без ошибок. QSPI он программирует за 6 минут - причем неважно 15 МГц, 10Мгц или 2 Мгц. Скорость не меняется. В процессе программирования ошибок нет, но они выявляются при проверке (и они действительно есть, если запустить устройство и посмотреть на залитые картинки). Если же поставить 1 МГц - то все без ошибок, программируется за 12-13 минут. По сравнению с ST-Link на меньшей частоте скорость получается больше. Но все же.... никак нельзя шить QSPI на большей частоте? Может саму QSPI надо как-то настраивать по другому? У кого какой опыт, расскажите, с какой скоростью, на какой частоте удавалось прошивать QSPI? Объясните мне, почему так получается - почему качество зависит от частоты J-Link? Насколько я понимаю, микросхеме дается команда на запись, а алгоритм и, тем более IDE, просто ждут отработки этой команды. В шею ведь микросхему никто не гонит? Настройки QSPI в алгоритме у меня такие.

Короче говоря, как выяснилось, у китайцев, продающих сие чудо, есть софт, который крякает все IDE, которые находит на компьютере. После этого сообщение о дефектном устройстве исчезает. Исчезли и проблемы с брейкпоиннтами. Правда первая попытка записи QSPI на максимально высокой частоте привела к множественным ошибкам. Попробую подобрать гарантированно безопасную частоту.

В qspi только данные. Где в keil проверить адрес точки останова и как его установить? Почему раньше у меня такой проблемы не возникало с stlink и H743/F746?

Вот смотрите, стирается внутренняя флеш, стирается qspi. начинается загрузка кода. Код во внутреннюю флеш грузится без проблем. Дальше грузится в qspi. Примерно на 200 КБ кода появляется это сообщение, о брейкпоинте. Ради интереса удаляю все брейкпоинты из текста основной программы, которые были поставлены для отладки. Теперь qspi программируется до 300 килобайтной отметки, после чего опять ругань на брейкпоинты. Какими были бы ваши действия? В st link такой ерунды не было.

Нет, причина была в том, что в файле JLinksettings.ini была запись Device=arm7. После исправления этой записи и установки последней версии софта, 6.98, все заработало. Кстати, запись "arm7" не мешает коннектиться к F746 Насчёт сообщения о дефективности, которое вылазит, китаей обещал прислать свой софт - HJink. С ним сообщение не должно появляться. Очень надеюсь, что перестанет появляться и сообщение о невозможности установки какого то брейкпоинта. Какие брейкпоинт могут быть в ходе заливки прошивки в qspi, кто нибудь может ответить?

АГА.... так причина описанного как раз в том, с чего мы начинали * JLink Info: Device "ARM7" selected. Осталось понять, блин, где в настройках мог быть указан ARM7 в качестве DEVICE? Вот моя вкладку Device, что не так?

Хм.... вот вам тогда загадка. Вот проект для Keil под H743 камень. Ничего не делаю такого, просто хочу с помощью IDE увидеть ядро (неважно какое). Открываю вкладку Debug, ядро не видно. Вот проект под F746 камень, НО ПОДКЛЮЧЕНА ПЛАТА С H743 камнем. О чудо, проект под другой камень, тем не менее, видит Н743 камень Найдите разницу в настройках вкладки Debug. Даю подсказку - никакой разницы нет. А если нет разницы, почему тогда все видится? И не там где нужно.

Откатилась на версию драйвера J-link 6.16 - стало распознаваться. STM32H743 - не видит в упор. Попробовала на F746 - видит, программирует. Правда прирост скорости не ахти - на ST-Link код некоего объема на частоте 1 МГц заливался (со стиранием) за 22 сек, на 10 МГц - за 12 секунд, на 50 МГц - за те же 12 секунд. Попробовала залить код в QSPI. Получаю вот что На определенном адресе выдает Cannot Setup BreakPoint at address Пардон, я всю жизнь думала, что брейкоинты используются при отладке, но не программировании? А если это не так - то где искать эти установленные брейкпоинты? О чем вообще речь? ЕЩе вопрос - у меня высталено интерфейс SWD (там можно выбрать SWD/JTAG). Но взгляните на скриншот. Мне кажется или система думает, что это JTAG (судя по надписи JTAG speed и названиям пинов) ?

"Там не ARM7" - там - это где? В программируемом контроллере или в ST-Link? Мой новый программатор - на LPC4337, на коробке написано -SWD. И почему, если в моем проекте в настройках указано ARM7 (как такое может быТЬ, если в настройках явно указан камень), то почему эта ошибка не вылазит при отладке через Link Зачем этот джампер внизу справа?

А почему, если я программирую через ST-Link, то его этот факт не смущает?

Не помогло. Точнее контроллер перестал ресетиться, но ядро все равно не распознается. Частоту меняла. Плату проверяла свисток ST-Link к ней коннектится. Ради интереса попробовала, что будет, если все же попытаться залить прошивку: Почему ARM7 not supported via SWD? У меня KEIL, если что...

Не совсем понимаю что значит "в лицензиях есть?" Была мысль. Но подкупила картинка с софтом и настройками. 430 рублей... Мне было бы сложнее разобраться с кусками кода с гитхаба, я с ужасом вспоминаю танцы с QSPI. Хотя по молодости принципиально не покупала программаторы для AVR, сама делала. А вот J-Link купила. Кстати о J-linke - ссылка на тему выше.

Спасибо! Гоу дальше помогать даме

Вот такой Китаеза-Link 11 версии https://aliexpress.ru/item/4001187150039.html?spm=a2g0s.9042311.0.0.768933edBhRfHc&_ga=2.128410890.746446631.1616923384-8145079.1577121024&sku_id=12000016695396048 Софт с компа (J-Link V6.95d) его видит Но ругается Подключаю к плате по интерфейсу SWD (всего 3 проводка - GND, SWDCLK, SWDIO, без ресета). Ядро контроллера не видится. Но если устройство работало, то оно тут же ресетится и останавливается. Что еще обратило на себя внимание (на скрине выше) - Vref равен 3.348V, хотя отлаживаемое устройство не подключено. Для сравнения подключил старый тоже китайский J-link -7 , прошитый под 8 версию, на него не ругается, и Vref честно равен 0 вольт. Как вылечить?

Вам наверное веселее пришлось бы, если бы вы продолжили эксперименты. У меня мой программатор перепрошился, и с родным софтом прошил флешку. Флешка впаяна. Монитор заработал. Программатор убран в ящик.

Ура!!! После перепрошивки надо было еще раз переустановить драйвер. Программатор определился!

Цирк с конями продолжается. ОКазывается, Dfuse при установке просто кидает драйвера в свою папку, а их еще и установить надо. Что ж дрова установлены, о чудо, DFuse видит "STM Device in DFU mode" и в соответствии с инструкцией https://static.chipdip.ru/lib/787/DOC002787931.pdf можно программатор перепрошивать. Перепрошиваю, прошивка проверяется, все ОК. Убираю перемычку.Включаю программатор - светодиод на нем не горит, программатор не видится системой никак. Программатор перепрошился все-таки. Но та же песня - не определяется....

ух ты... это что было, на какой плате и с каким кодом? Следующая же мысль. Возможно то, что вы залили в свою плату позволяет плате определяться как программатор RDC2, но будет ли ваша плата понимать настройки софта? У меня вообще какая-то странность, программатор видится системой, но не видится программой. И перепрошиваться не хочет, DfuSe_Demo от ST должен видеть "STM Device in DFU mode", а он не видит.

Хотелось побыстрее и с гарантией (смешно, правда?) Памятуя о мучениях с QSPI алгоритмом....

Друзья, понадобилось запрограммировать SPI Flash (сломался монитор, два дня ковыряний в нем вывели на слетевшую прошивку. Купила то, что было в нашем "сельпо" - вот такой привлекательный программатор https://www.chipdip.ru/product/rdc2-0026a Система подхватывает драйвера, устройство благополучно определяется в системе как CardLab - но прилагающийся софт не видит программатора. Пробовала перепрошить утилитой от ST - DFuse Demo - она тоже не видит устройство. Может кто пользовался таким? В чем может быть проблема? Поиск поддержки привел к гневным комментариям юзеров, что поддержка молчит.

Уважаемый, я стараюсь сделать дружественный для пользователя интерфейс. В окошке иконки двух носителей, хочется, чтобы отображалось состояние обоих, с изменением иконки. А состояния 3 - нет носителя, носитель есть и с ним не все в порядке, носитель есть и с ним все в порядке. у меня к Вам вопрос - а если пользователь надумает вставить USB флешку, не вынимая при этом SD карту, как тогда поведет себя ваш алгоритм? Вот хочу я видеть в окошке список файлов на SD карте, а в это время вставлять и вынимать USB флешку и наблюдать, как меняется иконка. Хочу чтобы как в компьютере выглядело, создавало впечатление проработанного и совершенного продукта. Пока что у меня это работает, но при условии, что я каждый раз при обращении к другому диску вызываю f_mount. Уважаемый, мой проект сгенерирован Кубом. В нем есть два отдельных файла - sd_diskio.c и usbh_diskio.c. Ничего не нужно переделывать и переадресовывать. Для каждого носителя написан свой код. Давайте так. За ваши советы по архитектуре спасибо, но я сделаю по своему. Мне лишь нужно понять, в чем ошибка. И, поверьте, причина ошибки не в том, что я делаю не так, как вы посоветовали. Хотелось продолжить повествование дальше, но, как мне кажется, на корень зла я все-таки вышла, попробую разобраться, потом отпишу.

Нажал иконку флешки - запустился один свич, в окошке вывелся список файлов на флешке. Нажал иконку карты - запустился другой свич, в окошке обновился список файлов. А мне одновременно работать не надо. Под одновременностью понимается возможность чтения/записи и того и другого в одной железке.

Посмотрите как сейчас. void SWITCH_to_USB() { CurrentPath="1:"; if (f_mount(&USBHFatFS, (TCHAR const*)USBHPath, 0) == FR_OK) { ReadDisk(); } } void SWITCH_to_SD() { CurrentPath="0:"; if (f_mount(&USBHFatFS, (TCHAR const*)SDPath, 0) == FR_OK) // ВОТ ЗДЕСЬ СДЕЛАНА ОШИБКА, ИЗ-ЗА КОТОРОЙ ТЕМ НЕ МЕНЕЕ, ВСЕ РАБОТАЕТ - вместо &SDFatfs указано &USBHFatFS { ReadDisk(); } } сделана ошибка, из-за которой почему-то все работает- вместо &SDFatfs указано &USBHFatFS Ошибка сделана в функции переключения на SD, но это влияет на работу USB. С однократным монтированием почему-то не выходит, при обращении к USB диску f_opendir отрабатывает нормально, но f_readdir возвращает FR_DISK_ERR нутри ReadDisk() вызывается f_opendir, в которую и подставляется CurrentPach

Дык исходники просмотрены, сделано по примерам Она знает об этом заранее oid MX_FATFS_Init(void) { /*## FatFS: Link the SD driver ###########################*/ retSD = FATFS_LinkDriver(&SD_Driver, SDPath); /*## FatFS: Link the USBH driver ###########################*/ retUSBH = FATFS_LinkDriver(&USBH_Driver, USBHPath); /* USER CODE BEGIN Init */ /* additional user code for init */ /* USER CODE END Init */ }

Нет там селектора, просто указывается путь. 0: и 1: в начале пути - это и есть селекция.