Здравствуйте. Подскажите пожалуйста в чем дело. ПРИ НЕ ПОДКЛЮЧЕНОМ УСТРОЙСТВЕ к PC построеном на STM32F103RC постоянно срабатывает прерывание USB_LP_CAN1_RX0_IRQn. На ногах все чисто (асцилограф). Частота очень высокая занимает почти все процессорсое время. Если использовать очередь (семафор) то обработчик неуспевает вызываться. Все это видно дебагером. Флаги ISTR_ERR и ISTR_ESOF. Если нужен код скажите

Очевидно дело в том, что где-то в коде это прерывание разрешено и более того прерывания от соотв. периферии тоже разрешены,
но при этом обработчик прерываний отсутствует или подключен неправильно (написан в С++ без соотв. extern "C").

Улыбнуло

Ни в коем случае!
С подобной элементарной задачей крайне важно разобраться самостоятельно, в противном случае придется поменять профессию

Уважаемый Forger Ваша ирония мне конечно подуше (немного разрядки - 2 сутки с USB) но тут Вы абсолютно НЕПРАВЫ. Обработчик присутствует и если вы работали с данной переферией то он стандартный если брать STM32_USB-FS-Device (проверят все возможные флаги относительно данной переферии).

ЧТО ЗАМЕЧЕНО:
Прерывания срабатывают после рестарта проца (USB не подключено к PC) и после нескольких дрыгов, завтра посчитаю, затихают. При этом флаги выставляются ERR, ESOF, SUSP. Далее вроде тишина пока не подключешь USB. Просмотрено дебагером.

Странно что при старте флаги маскируются ( PowerOn() )
wInterrupt_Mask = CNTR_RESETM | CNTR_SUSPM | CNTR_WKUPM;
_SetCNTR(wInterrupt_Mask);

а далее вызывается функция USB_SIL_Init(); в которой все это дело открывается:
wInterrupt_Mask = IMR_MSK;
_SetCNTR(wInterrupt_Mask);

Причем вызовы идут подряд.

ЧТО ЭТО И КАК РЕШИТЬ

Это невозможно, поскольку после сброса все прерывания от периферии отключены да вообще вся периферия отключена (тактирование).
По крайней мере так реализовано у ST, даже если было вызвано программное прерывание (через SystemReset).
Но, если ваш МК ведет себя не по даташиту, то пишите сразу в ST, а не сюда.


Спешу огорчить - эти 2 дня убиты впустую, ибо ищутся подобные ошибки за 10 минут с перекурами

Делается классически: подключаете отладчик и по шагам смотрите кто и где разрешает ненужные прерывания.
Если не получается, то отрезаете куски кода, пытаясь локализовать кто пакостит.

Если работаете с кубом, то все сложнее, но тоже поправимо, принцип такой же, только времени потребуется скорее всего заметно больше.

Наблюдал подобное поведение на SMT32L4,

Так же бы флаги ISTR_ERR и ISTR_ESOF. Проблема проявлялась только в том случае, когда Vusb был подключен к отдельному напряжению питания USB PHY 3V0, питание VDD, было 1V8.

Решал проблему через привязку включения USB к моменту физического подключения, и соответственно выключения. В моем случае помог флаг PWR_SR2_PVMO1 и HAL_PWREx_PVM1Callback но, на сколько я помню на F103 такого еще нет(могу ошибаться), поэтому необходимо подключать пин для детекта наличия Vusb

Огромное спасибо. Это действительно наверно сработает (необходимо подключать пин для детекта наличия Vusb) в данный момент как я понял необходимо отключить флаг SUSPEND что не даст возможность взводить ISTR_ESOF. Пока у меня это работает но при этом есть проблема, если хост засыпает то вешается проц. Возможно подключение даст возможность по детекту взводить отключеные флаги. ПОПРОБУЮ