Есть проект, основанный на ST MassStorage примере. Кроме того, добавлен мой код для работы с UART.

Иногда работает без проблем, иногда на старте умирает. Причем умирает так, что дебагером уже не подключиться. Проблема явно в коде, связанном с USB. Если идем по шагам в дебагере - все работает. Как только убираю все брек поинты и продолжаю бежать код - то одно из двух. Или все работает долго и счастливо. Или затыкается совершенно. Так что отладчик в Кейле выдает ошибку "Cannot access target. Shutting down debugging session" После того подключиться можно только после сброса питания процессора. Похоже, что проблема возникает, если мое устройство не обработало вовремя какой-то пакет от USB хоста.

Кто-то может посоветовать - как узнать, что случилось перед смертью?

Если нога reset тоже помогает, то можно писать какой-то лог в ОЗУ. Поставить точку останова перед процедурой инициализации, чтобы после сброса можно было прочитать содержимое лога перед его затиранием.

А нигде в коде не встречается следующая строка:

AFIO->MAPR = (AFIO->MAPR & ~AFIO_MAPR_SWJ_CFG) | AFIO_MAPR_SWJ_CFG_DISABLE; ?

Это отключение JTAG.

Я отлаживаю через SWD, не через JTAG. И борд действительно умирает - перестают даже мигать леды, что переключаются в каждом интерапте.

Писать в RAM, а потом читать после ресета - идея красивая. Вот только я не знаю, где именно происходит проблема. Дебаге весь код проходит отлично. Да и так работает с вероятностью 70 процентов. Ставить "маячки" на прохождение каких-то точек можно. Но кода в USB много.

У меня сложилось впечатление, что как работает USB не знает никто . Все берут какой-то пример с USB от третьих лиц, и вокруг уже накручивают свою функциональность, стараясь не прикасаться к USB.

Судя по всему - проблема на этапе распознавания USB устройства компьютером.

А это все под какой-нибудь ОС вертится? Может, просто стека не хватает
Попробуйте для исключений написать заглушки, чтобы определяли хоты бы адрес, из которого туда попали

Нет никакой ОС. Есть пример MassStorage, где весь код работает в прерывании.
Есть SD card, для которого реализованы синхронные запись и чтение блока
Есть UART - в интеррапте берутся полученные байты и складываются в буфер
И есть цикл, который смотрит - не пришло ли что-то из UARTа, и если пришло - то обрабатывает. Когда накопится достаточно информации - записывает данные на карту, используя FatFS

Затык происходит во время инициализации USB. Похоже, что если устройство замешкается и не обработает вовремя пакет от хоста - то происходит сбой. А точнее поймать ничего не могу.

ну так процессор-то все равно должен где-то вертеться??
напишите заглушки для exception, примерно такие:



ну и в стартапе их прописать

запуститься из-под отладчика и ждать сбоя
как раз будет понятно, какое исключение случилось и откуда оно случилось

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

А у меня - процессор не реагирует, из отладчика вываливается с сообщением "Cannot access target. Shutting down debugging session". Снова подцепиться дебагером не могу, пока не дерну ножку ресет

Я несколько продвинулся. Скорее всего, проблема в том, что есть код в usb_pwr.c, который отправляет процессор спать (suspend). Похоже, что этот сон слишком глубокий для моего устройства.
Я пытался решить проблему в лоб - изменить флаг fSuspendEnabled на FALSE. Это помогло, в том смысле, что теперь процессор не отваливается. Но у хоста занимает много времени распознать устройства. Так-же перестали приходить прерывания USBWakeUp.

Если кто-то натыкался на эту проблему - поделитесь знаниями, пожалуйста. Я пока погуглил "STM32 USB fSuspendEnabled trouble", и понял что не одинок в своей беде. Но решения еще не нашел.