Пример из последнего Keil из пакета ARM\Pack\Keil\STM32F1xx_DFP\1.0.5\Boards\Keil\MCBSTM32E\Middleware\USB\Device\HID\ пытаюсь приспособить под плату MCBSTM32. Есть отличия в схемах, поправил, как смог. Собственно, мне и нужно только светодиоды включать да кнопки опрашивать. С помощью HIDClient, оттуда же, из Keil.
Но пока что компьютер выдает "Устройство USB не опознано". Прилагаю лог, собранный с помощью USBTrace. Что это значит? Такое впечатление, что дескрипторы неправильные, если они вообще есть. В проекте найти их пока не смог, и не создавал. После сброса на USB секунд 5 что-то болтается, потом - тишина.
Полная версия этой страницы: USB HID из STM32F1xx_DFP
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
Попробовал запустить старый проект HID для MCBSTM32, скачанный с сайта Keil. Который работает нормально.
Вижу, в строке 8 пересылка удалась.
Вижу, в строке 8 пересылка удалась.
В старом рабочем проекте после инициализации крутится пустой цикл. По прерываниям работает. Когда в отладчике ставлю в нем точку останова, так же отваливается шина.
Насчет остановки в цикле - надо думать, не успела пройти вся инициализация (энумерация), потому устройство и было отключено от шины.
Может быть, и в нерабочем проекте что-то мешает ответить в срок на запросы от хоста.
Может быть, и в нерабочем проекте что-то мешает ответить в срок на запросы от хоста.
Копаю дальше.
Смотрю осциллографом сигналы D+ D-, декодирую сам. Вижу после сброса на шине регулярно через 1 ms идут пакеты SOF, за ними IN к uLink-ME, намного реже идут PRE low_speed и IN к мышке. Найти обращения к нулевому адресу так не получается.
Зато заметил, что несколько раз на шине появляется сброс (оба сигнала в низком уровне, длительностью около 10,5 ms). Вот по этому сигналу засинхронизировался. Последнее, что передается к нулевому адресу, это SETUP и DATA1 (Get_Descriptor устройства, который предполагает 0x40 байтов данных).Но вместо данных идет пакет DATA0 вроде как без данных, но с CRC16. И такой набор пакетов повторяется 3 раза, затем через несколько кадров хост отключает этот сегмент шины, и уже ничего нет (Idle).
Пытаюсь увязать то, что вижу я, с тем, что видят USBtrace и USBlyzer. Каждый видит своё.
upd. Посмотрел еще раз, пакета DATA0 не увидел.
Смотрю осциллографом сигналы D+ D-, декодирую сам. Вижу после сброса на шине регулярно через 1 ms идут пакеты SOF, за ними IN к uLink-ME, намного реже идут PRE low_speed и IN к мышке. Найти обращения к нулевому адресу так не получается.
Зато заметил, что несколько раз на шине появляется сброс (оба сигнала в низком уровне, длительностью около 10,5 ms). Вот по этому сигналу засинхронизировался. Последнее, что передается к нулевому адресу, это SETUP и DATA1 (Get_Descriptor устройства, который предполагает 0x40 байтов данных).
Пытаюсь увязать то, что вижу я, с тем, что видят USBtrace и USBlyzer. Каждый видит своё.
upd. Посмотрел еще раз, пакета DATA0 не увидел.
Да... попался я. Имею в начале программы 2 библиотечных функции. Что они делают, не видно.
После второй программа улетает в HardFault с симптомом:
Код
USBD_Initialize(0); /* USB Device 0 Initialization */
USBD_Connect(0); /* USB Device 0 Connect */
USBD_Connect(0); /* USB Device 0 Connect */
После второй программа улетает в HardFault с симптомом:
Цитата
Bit possible Causes
INVSTATE (bit 1) 1. Loading branch target address to PC with LSB equals 0. Stacked PC should
show the branch target.
2. LSB of vector address in vector table is 0. Stacked PC should show the starting
of exception handler.
3. Stacked PSR corrupted during exception handling, so after the exception the
core tries to return to the interrupted code in ARM state.
INVSTATE (bit 1) 1. Loading branch target address to PC with LSB equals 0. Stacked PC should
show the branch target.
2. LSB of vector address in vector table is 0. Stacked PC should show the starting
of exception handler.
3. Stacked PSR corrupted during exception handling, so after the exception the
core tries to return to the interrupted code in ARM state.
Ошибка оказалась в другом. Мало выделил стеков под задачи в RTX. Там только для USB две задачи работают. В-общем, подогнал, как в примере для MCBSTM32E, заработало.
В-общем, про задачи и стек написано в html-документации на USB Component, которая записывается при установке Keil. Нужно было дочитать...
Попытался аналогичным образом создать VirtualCOM, и снова имею те же проблемы - секунд 5 на шине бегают сигналы, после останавливается, компьютер пишет "Устройство USB не опознано". Что-то я разочарован Keil-овским USB Component. Попрятали все функции в библиотеки, еще и RTX свою приплели.
Вообще, дурдом. Шина начинает "шевелиться" еще до выполнения функций
USBD_Initialize(0); /* USB Device 0 Initialization */
USBD_Connect(0); /* USB Device 0 Connect */
Вижу, ходя по функциям.
upd. Заработало и это. Переместил галочки в примере на F107 в RTE_Device.h USB OTG ... на USB Device, для F103.
Как побежало по шине, сплошным потоком! Что передают? Я пока ничего не пересылаю.
Вообще, дурдом. Шина начинает "шевелиться" еще до выполнения функций
USBD_Initialize(0); /* USB Device 0 Initialization */
USBD_Connect(0); /* USB Device 0 Connect */
Вижу, ходя по функциям.
upd. Заработало и это. Переместил галочки в примере на F107 в RTE_Device.h USB OTG ... на USB Device, для F103.
Как побежало по шине, сплошным потоком! Что передают? Я пока ничего не пересылаю.
Теперь такой вопрос - каким образом задаются параметры COM порта? Вижу в USBD_User_CDC_0.c функцию
Похоже, нужно послать по USB запрос на установку режимов, они одинаковые и для VirtualCOM, и для COM (символы передаются с одного порта на другой, и наоборот, в данном примере). Но что-то я не нахожу, где и когда создается такой запрос. В настройках COM (VirtualCOM) порта в Windows?
Код
// Called upon USB request to Set Line Coding.
// \param[in] line_coding pointer to \ref CDC_LINE_CODING structure.
// \return true set line coding request processed.
// \return false set line coding request not supported or not processed.
bool USBD_CDC0_ACM_SetLineCoding (CDC_LINE_CODING *line_coding) {
if (Driver_UART1.Configure ( line_coding->dwDTERate,
line_coding->bDataBits,
(ARM_UART_PARITY) line_coding->bParityType,
(ARM_UART_STOP_BITS) line_coding->bCharFormat,
ARM_UART_FLOW_CONTROL_NONE)
== ARM_UART_OK) {
LineCoding.dwDTERate = line_coding->dwDTERate;
LineCoding.bDataBits = line_coding->bDataBits;
LineCoding.bParityType = line_coding->bParityType;
LineCoding.bCharFormat = line_coding->bCharFormat;
}
return true;
}
// \param[in] line_coding pointer to \ref CDC_LINE_CODING structure.
// \return true set line coding request processed.
// \return false set line coding request not supported or not processed.
bool USBD_CDC0_ACM_SetLineCoding (CDC_LINE_CODING *line_coding) {
if (Driver_UART1.Configure ( line_coding->dwDTERate,
line_coding->bDataBits,
(ARM_UART_PARITY) line_coding->bParityType,
(ARM_UART_STOP_BITS) line_coding->bCharFormat,
ARM_UART_FLOW_CONTROL_NONE)
== ARM_UART_OK) {
LineCoding.dwDTERate = line_coding->dwDTERate;
LineCoding.bDataBits = line_coding->bDataBits;
LineCoding.bParityType = line_coding->bParityType;
LineCoding.bCharFormat = line_coding->bCharFormat;
}
return true;
}
Похоже, нужно послать по USB запрос на установку режимов, они одинаковые и для VirtualCOM, и для COM (символы передаются с одного порта на другой, и наоборот, в данном примере). Но что-то я не нахожу, где и когда создается такой запрос. В настройках COM (VirtualCOM) порта в Windows?
Да, так и есть. К плате MCBSTM32 подключил от компьютера два кабеля - один USB, другой RS-232. В одном HTerm подключаюсь к COM3(VirtualCOM), задаю скорость (до 115 200 работает безупречно) и остальное, в другом HTerm подключаюсь к COM1, настраиваю те же параметры. В одном HTerm посылаю символы, в другом принимаю. Круто.
А примеры готовые посмотреть - на крайний случай можно гуглом.
Я вот когда-то делал HID (CMSIS-DAP debugger) и CDC для всякой фигни отладочной - всё на F103
Проблем особых нет - особенно когда есть дебаггер (любой)
можно просто скачать - поменять обратотку hid пакетов если надо
https://github.com/x893/CMSIS-DAP
cdc он и в африке cdc
P.S. При наличии отладчика 99% вопросов должны отпадать сами собой
Я вот когда-то делал HID (CMSIS-DAP debugger) и CDC для всякой фигни отладочной - всё на F103
Проблем особых нет - особенно когда есть дебаггер (любой)
можно просто скачать - поменять обратотку hid пакетов если надо
https://github.com/x893/CMSIS-DAP
cdc он и в африке cdc
P.S. При наличии отладчика 99% вопросов должны отпадать сами собой
Цитата(x893 @ Apr 26 2014, 22:29) 
Я вот когда-то делал HID (CMSIS-DAP debugger) и CDC для всякой фигни отладочной - всё на F103
Проблем особых нет - особенно когда есть дебаггер (любой)
Проблем особых нет - особенно когда есть дебаггер (любой)
Всё когда-то бывает в первый раз. Примеры из Кейл я попробовал. Но там всё уже запрятано в библиотеки, к тому же, использует RTX. Думаю, это сказывается на производительности. Будет время, сделаю свое.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.