Вы всё обещаете, но никак не уходите. Помощи от вас никакой, только тему засоряете.
Автор темы давно убрал глухой цикл из прерывания, а вы продолжаете ему твердить про это.

Вообще, я первый раз такое вижу - "HAL не пробовал, но он прекрасен". Этакое "Рабинович напел" наоборот.



Посмотрите настройки флеша. wait-states, ART prefetch. Если у вас старая ревизия контроллера (какой кстати контроллер?), то там были баги в ART prefetch. Возможно, куб включает ART безусловно, и проблема в этом.

Да не расстраивайтесь вы так за ТС, он не маленький, сам разберется, хоть и не сразу ...


© "Читаю книгу, а вижу фигу"
Внимательнее читайте порядок действий, которые я уже неоднократно приводил для ТС. Продублирую:



Может еще нужно разжевать до косточек и написать проект за самого ТС???


Не пойму, какое отношение подобные домыслы имеют к этой теме и ко мне лично?

Я пользуюсь HAL (ранее SPL), ничего дурного в этом не вижу. Но без соотв. тестов слепо доверять бесплатному чужому коду тоже не стану.

То есть, для отладки USB вы предлагаете выбросить USB? Ну, нормально, да. То-то автор темы так оценил вашу помощь.


Я имел в виду куб, не думал, что есть разница между HAL и кубом. Вот та цитата, от которой я отталкивался:

И откуда ж вы такие умные беретесь, а? Для начала хорошенько почитайте тему.
Кратко для ленивых: проблема в данном случае вовсе не в CUBE/HAL/USB, а т.н. user-коде. Без самодеятельности ТС все там работает (с его же слов).


Ну, коли вы не видите разницу между красным и мокрым, то сначала изучите матчасть, перед тем, как кидать кирпичи.

Ревизия проца A. Две штуки. Взял вторую плату, китайский клон Nucleo. Результат тот же. Сделал передачу по уарт ногодрыгом вручную. Аппаратный отключен. То же самое. При передаче первого байта отваливается USB. Такое впечатление, что любая запись в порт PA валит USB. Он тоже на этот порт выведен.

Чудеса да и только!
Другой USART или этот же, но в другие пины работает так же?

Выкладывайте код вместе с инициализацией и на всякий случай схему.

Руководство по поиску причины HardFault

А какой проц-то? В F405/407/415/417 - ART не рабочий в ревизии A. Если куб его включает, то причина вылетов может быть в этом.
Кроме того, проверьте частоту, на которую вы настроили PLL. Правильно ли задана частота кварца.


Я вообще-то высказывался не против CUBE/HAL/USB, а против вашего способа "помогать" автору темы. Вы не помогаете. Вы чешете своё ЧСВ.


Разницу вижу. Повторюсь: я имел в виду куб. Вы, не пользуясь кубом, тем не менее уверены, что проблема в пользовательском коде. Вот это я и имел в виду под тезисом "анти-Рабинович напел".

Читайте отсюда.

Вот кратко:



Вот код этой функции.

И тут почитайте: https://electronix.ru/forum/index.php?s=&am...t&p=1483529

Еще есть вопросы?


Увеличение размера стека помогает?

Процессор F411RE, ревизия A. Весь код генерит куб, я только компилирую его в кейле. Частоты не превышают ограничения в кубе (100Мгц и 50Мгц).

Одна плата такая: XNucleoF411re. Схемы нет.
Вторая плата такая:

Нажмите для просмотра прикрепленного файла

Схема есть.

UART. На другой порт перебрасывать - не выход. Все пины проца заняты. И плата уже разведена. И нет гарантии что при манипуляции другими битами порта USB не будет отваливаться.



Всю портянку, что куб нагенерил, выкладывать?

Да временно, чисто для поиска источника косяка. В подобных случаях нужно все пробовать!

И еще раз повторюсь - увеличение объема стека помогает или нет? Вообще-то это самое первое, что следует проверить в глючном кода.



Конечно же, никакие портянки сюда не надо выкладывать. Киньте все в один архив. Проект целиком, вместе с проектом под куб.

Ну на Nucleo-то можно попробовать?


Я всю тему читал, причём внимательно. Вижу, что код записи в UART вполне нормальный. Если только не включены прерывания от UART, то всё вполне легитимно. А теперь автор темы убрал ожидание флагов UART в прерывании. Всё должно работать.

Внутри прерываний висит, вне - работает.
Отсюда простой вывод, что проблема на 99,9% в юзер-коде или настройках проекта (я бы для начала проверил объем стека, всякое бывает).

Насколько я понял, в последнем варианте в прерывании он пишет в буфер в памяти, а в UART вываливает потом, из основного кода.
Стек там не используется почти, так что вряд ли в нём дело. Я подозреваю неправильные настройки тактирования или включенные случайно прерывания от UART.

Именно поэтому я настаивал на новом проекте, где бы полноценно отдельно был отлажен весь этот код, в противном случае траблы будут возникать на казалось бы ровном месте.

Как пришлет проект целиком, станет все понятно.

Нажмите для просмотра прикрепленного файла

Размеры стека и кучи я увеличил в два раза по сравнению с теми, что поставил куб.

Мои добавления только в файле main.c между стоками со звездочками. Все остальное сгенерил куб.
У меня работает так:

Подключаю. Устройство определилось.
Пауза.
Когда начинается вывод через UART, устройство отваливается и переподключается. Вижу по USBLyser-у.
И так по циклу.

Вот так нужно было сделать в самом первом посте

Проверьте линии TX/RX аппаратно на плате, нет ли соплей и т .п.

Если временно использовать другой USART на других пинах, то проблемы остаются?

Пины проверил, одинаково не работает на ДВУХ разных платах. Под другой порт переделываю.

Все, нашел.

Куб в коде выставляет в USBD_LL_Init():

hpcd_USB_OTG_FS.Init.vbus_sensing_enable = ENABLE;

Даже если в настройках USB в кубе переключатель Activate_VBUS отключен. А VBUS_DETECT это пин PA9, он же и TX для USART1.

И возникает конфликт между USATRT1 Tx и VBUS_SENSE. Поэтому отваливается USB, если что-то делать с пином PA9 (или передавать через USART1 или вручную им шевелить)

Но если выбрать переключатель Activate_VBUS и USART1 одновременно, то тогда передачу USART1 он монтирует на PA15, на PA9 VBUS_DETECT и конфликта нет.

Сделал вручную в коде

hpcd_USB_OTG_FS.Init.vbus_sensing_enable = DISABLE;

Все работает.

Тоже грешил на этот PA9, потому и просил кинуть пины в другой USART или другие пины.

Но смотря в КУБ, вижу, что он тут ни при делах, все дело в вашей самодеятельности. Поясню:

До того, как будет вызвано MX_USB_DEVICE_Init, где V_BUS настраивается уже правильно, вы пытаетесь кидать в USART байты:



Это можно делать только в тех секциях, где это разрешает КУБ.
В данном случае достаточно перенести ваш код в место между этих строк: /* USER CODE BEGIN 2 */ и /* USER CODE END 2 */.

Внутри MX_USB_DEVICE_Init() и есть настройка

hpcd_USB_OTG_FS.Init.vbus_sensing_enable = ENABLE;

Я потому и поставил первую строку приветствия до MX_USB_DEVICE_Init(). Если поставить после нее, то будет происходить передача строки и одновременно обмен по USB (инициализация), тогда USB отваливается.

Гы-гы-гы, повеселили!
5 страниц увлекательного чтива!

И после этого не курить даташиты с рефманами и не вручную периферию настраивать?!

Ясно, и больше она нигде не менятся другую....

Что ж, лишний гвоздь в гроб куба!
Как был он уделом новичков и школоты, так он таковым и остается.

Короче, живем по-старому - все настраиваем ручками, и неважно как с HAL/SPL или без. Главное, ручками !!

Впрочем, в кубе удобно глядеть визуально где какой пин будет висеть и прикинуть на будущее трассировку и назначение пинов по AF-функциям...
Но упаси боже вставлять в проект нагенерированный им код!

Ага, у меня уже даже привычка появилась. Сначала генеришь все на кубе, убеждаешься, что ничего не работает, оставляешь только инициализацию, а все остальное преписываешь поглядывая в код куба.

Чтобы распределять пины, я в OO Calc нарисовал простыню - в колонках пины, в строках периферийные устройства, в клетках - возможные соединения, закодированные одной буквой/цифрой(например, для SPI - MISO - I, MOSI - O, SCK - K, CS - C, SS - S). Сразу все возможности видны на одном листе.

Если не BGA-корпус, то просто распечатать pinout и вручную функции разложить, всё равно время сэкономит по сравнению с поиском косяков "визуальных" (;