Кто любит RISC в жизни, заходим, не стесняемся.
Ответить

Re: STM32 и USB (практика)

Ср апр 19, 2017 15:53:38

Я думаю это NAK-ответ от МК. Узкий импульс может быть следствием плохого контакта. Ведь на второй линии все ок. А там сигналы вроде как в противофазе идут.
Вложения
NAK.jpg
(162.3 KiB) Скачиваний: 763

Re: STM32 и USB (практика)

Чт май 04, 2017 08:55:04

Всем привет.
Сразу извеняюсь за ошибки.
NAC это пакет квитации. А конец пакета это два такта .
После энумерации. Host начинает работат. Как часто он будет опршивать конечные точки это записано в дескрипторы.
Дапустим ENP1 IN это данные для Host . Если в дескрипторе 0 то каждом кадре будет обращение к эндпонту.
Но тут есть одна интересная вещь. Эсть два ПИДа DATA0 DATA1.
После Reset все 0. STM32 там тоже DTOG_TX=0 это DATA0. А Host запрашывает DATA1. Конешно ответ NAC. В следующем фреме тоже повторитьса.
Но у вас есть даные которые надо атправит Hostу. Запишыте даные в ENP1 IN буферь и количество. Даные подготовленые можно послать. Это просто изменяем значение DTOG_TX=1. Даные ушли . При получении ACK значить всё хорошо. А при NAC Host в следующем фреме повторит запрос DATA1. А ACK следующий запрос будеть DATA0. Но STM32 стоит 1 это DATA1 значить на запросы ответить NAC. И так будеть продожатса долго. Но у STM32 есть даные которые надо отправить. Данные в буфер счёчик и DTOG_TX=0. И всё :)) :)) :)) :)) :))

Re: STM32 и USB (практика)

Вс июн 25, 2017 22:48:55

Вечер добрый. Возникла проблема с STM32F042 HID:
1)при первом включении девайса к ПК пишет "запуск этого устройства невозможен (код 10)". При перетыке данная
ошибка больше не повторяется в принципе. Удаление устройства из системы к повторению ошибки не приводит.
В чем может быть причина такого поведения? Копать дескрипторы?

Re: STM32 и USB (практика)

Пн июн 26, 2017 11:51:11

Вечер добрый. Возникла проблема с STM32F042 HID:
1)при первом включении девайса к ПК пишет "запуск этого устройства невозможен (код 10)". При перетыке данная
ошибка больше не повторяется в принципе. Удаление устройства из системы к повторению ошибки не приводит.
В чем может быть причина такого поведения? Копать дескрипторы?


Скорее всего дело в них. Или в линии USB. Хотя у меня была как-то проблема. Но писал он, что устройство неопознанно. Но это был косяк с Windows. Бывало такое, но очень редко.

Re: STM32 и USB (практика)

Сб сен 02, 2017 18:22:02

Подключаю по USB-Host (без класса) тепловизор FlirOne Gen 2 к STM32F4Discovery. Устройство через раз находится, энумерация проходит, интерфейсы определяются, но данные не приходят. Делал по аналогии с этой статьёй. Проект создавал в CubeMX.

Собственно, вот основа проекта:


Данный тепловизор я успешно запускал по USB и в Linux, и в Windows и в QNX - т.е. протокол обмена точно верный.
Вот что ему нужно послать как управляющее сообщение:
Код:
   /* Flir config
   01 0b 01 00 01 00 00 00
   0 bmRequestType = 01
   1 bRequest = 0b
   2 wValue 0001 type (H) index (L)    stop=0/start=1 (Alternate Setting)
   4 wIndex 01                         interface 1/2
   5 wLength 00
   6 Data 00 00
   */


Сначала нужно остановить интерфейсы 1 и 2, а потом включить. И всё. Но не отвечает совсем по USB. USBH_LL_GetURBState возвращает USBH_URB_IDLE - я так понимаю, данные не принимаются.
Может быть, кто-нибудь знает, что я сделал неверно?

Re: STM32 и USB (практика)

Пн сен 04, 2017 18:47:24

Смотрю, что устройство присылает в дескрипторе интерфейса STM32F: у конечных точек wMaxPacketSize=64. Но они типа Bulk и в линуксе устройство отвечает так ( lsusb -vvv ):

Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 240
bInterfaceProtocol 1
iInterface 6 com.flir.rosebud.fileio
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1



Почему же тепловизор сообщает STM32F, что у него 64 байта размер передачи? Может, это USBH при инициализации чего-то передал тепловизору, что тот решил сократить размер конечной точки? Возможно ли такое? Я использую USB-Full Speed. Пробовал с LOW_SPEED (1.5 МБ/с) и HEIGHT_SPEED (12 МБ/с). Результат одинаковый. Там действительно приходит 64 байта для любой конечной точки.
Кстати, кто-нибудь знает, после SetInterface на интерфейс не содержащий конечных точек и обратно нужно заново делать USBH_OpenPipe? В библиотеке внутри постоянно делается USBH_OpenPipe - но... зачем? Ну и ещё одна странность - bAlternateSetting=0 у интерфейсов 1 и 2 есть по две конечные точки. При bAlternateSetting=1 точек нет ( там задан 0). Но тепловизор запускается как раз по командам SetInterface с bAlternateSetting=0, а потом bAlternateSetting=1. То есть, переключением в интерфейсы БЕЗ конечных точек! Почему тогда он работает в операционках? Или этот номер условный и bAlternateSetting=1 может выбирать интерфейс с конечными точками?

Re: STM32 и USB (практика)

Вт сен 05, 2017 10:53:29

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

Re: STM32 и USB (практика)

Вт сен 05, 2017 11:10:31

Спасибо за идею! Интересная мысль. Я обнаружил, что запрос к конечной точке GET_STATUS не проходит для конечных точек как раз настраиваемых интерфейсов (с возможностью отключения конечных точек) - ошибка "не поддерживается". Но после выполнения переключения интерфейсов в вариант без конечных точек запрос проходит. То есть, конечные точки оживают. Но не хотят ничего передавать - они должны непрерывно передавать. Запросы GET_INTERFACE (в котором можно было бы узнать, как сконфигурирован интерфейс) к настраиваемым интерфейсам, к сожалению, не проходит - ответ usb-модуля контроллера также "не поддерживается". Я посмотрел дескриптор конфигурации побайтно - там на самом деле максимальный размер пакета для всех конечных точек задан в 64 байта. А должно быть 512 (кроме точек для управления). Операционки сообщают именно о 512 байтах. Я не понимаю, как такое возможно? :roll: И подозреваю, что в этом размере всё дело - тепловизор отказывается передавать данные с таким размером передачи.

Всё, данные пошли. :))) Оказывается, при задании конечной точки в OpenPipe нужно указать точный размер канала, который прислал тепловизор. Я заменил на 64 и данные пошли.

Re: STM32 и USB (практика)

Ср сен 06, 2017 19:55:33

Мне объяснили, в чём дело. :) У Full Speed и ниже устройств максимальный размер буфера 64 байта. А у High Speed 512. Вот поэтому и такой маленький буфер.
Кстати, может кто знает ответы на следующие вопросы?

1) Если частота опроса 1 кГц, а за раз передаётся 64 байта, то за секунду можно передать с одного устройства всего 6400 байт? Но это ведь не так — иначе тепловизор бы нифига не работал бы с USB 1.0 и LOW_SPEED на PC.
2) Что такое USBD и чем оно отличается от USBH? Я так понимаю, USBD более высокий уровень и использует USBH?
3) Правильно ли я понимаю, что USB у STM32F4 требует непрерывного вызова функции USBH_Process? То есть, если с этим вызовом помедлить, то USB отвалится?
4) Правильно ли я понимаю, что USBH_BulkReceiveData работает в фоне с помощью этого самого USBH_Process? То есть, если USBH_Process не взывать, то USBH_BulkReceiveData не будет работать? Дело в том, что у меня USBH_BulkReceiveData при буфере отличным от 64, мягко говоря, работает от случая к случаю (но чаще не работает вовсе). Да даже при буфере в 64 точки приходит 35, 40, 63 и подобное количество байт. Но тепловизор, я знаю, фигачит не переставая. Куда же делись эти данные?
5) Можно ли как-то ускорить опрос устройства (опрашивать не 1 кГц, а чаще)?

Спасибо.

Re: STM32 и USB (практика)

Сб сен 09, 2017 19:34:24

Добрый день, знатоки stm32!
Если не затруднит, поделитесь пожалуйста рабочим примером работы с USB флешкой с использованием FatFs (на Keil или CooCox).
Интересует именно с использованием SPL, а не CUBE.
МК - stm32f407zet6.
На кубе получилось запустить, пробовал создать файл, писать в него, читать, всё работает.
В примерах на SPL, которых удалось найти, или функции файловой системы не работают или вообще не компилируется проект.
Спасибо!

Re: STM32 и USB (практика)

Сб сен 09, 2017 19:58:38

SPL CooCox, SPL можно даже легко подчистить - там практически только работа с портами через SPL. В Keil портируется.
http://mikrocontroller.bplaced.net/word ... ge_id=1333

Re: STM32 и USB (практика)

Сб сен 09, 2017 21:48:37

Находил именно этот же пример, но на сайте "Паяльник" http://cxem.net/mc/mc366.php
И там он был абсолютно нерабочий!
Этот же превосходно работает.
Огромное спасибо!

Re: STM32 и USB (практика)

Пн сен 11, 2017 17:26:49

Однако, рано я обрадовался.
При попытке портировать в Keil uVision5 перестало работать.
В режиме отладки функция UB_USB_MSC_HOST_Do() в цикле всегда возвращает статус USB_MSC_DEV_DETACHED
Настройка тактирования и в Keil и в CooCox одинаковая (функция SystemInit() ).
В чём может быть причина?

Re: STM32 и USB (практика)

Сб сен 16, 2017 07:41:32

Проблема всё ещё актуальна. Никто не поможет?

Re: STM32 и USB (практика)

Сб сен 16, 2017 08:50:54

для F401 тест портированый, вроде работал, железка "уехала" - проверить не могу
USBHostDemoF401.zip
(379.98 KiB) Скачиваний: 276

Re: STM32 и USB (практика)

Сб сен 16, 2017 15:44:42

Разобрался.
Оказалось всё дело в уровне оптимизации проекта. У меня изначально был 0 и поэтому ничего не работало (странно, почему так?).
Поставил Level 1 и заработало.
Я раньше думал, что уровень оптимизации это какой-то мифический, мало на что влияющий (по крайней мере на аппаратную часть) параметр в Keil. По умолчанию, при создании проекта всегда 0 и никогда не менял его.

Добавлено after 3 hours 5 minutes 17 seconds:
oleg110592, в вашем примере системная частота 84MHz, а хотелось бы на максимальной работать.
Если делаю 168MHz, USB перестаёт работать. Причём частоту тактирования шины USB оставляю 48MHz.
Файл system_stm32f4xx.c создаю с помощью STM32F4xx_Clock_Configuration_V1.1.0.xls
Вложения
system_stm32f4xx.c
С такими настройками USB не работает
(21.46 KiB) Скачиваний: 613
system_stm32f4xx.c
А с такими работает
(21.47 KiB) Скачиваний: 361

Re: STM32 и USB (практика)

Вс сен 17, 2017 06:52:29

у меня 84 максимум микроконтроллера, а если настройки как куб советует сделать:
Изображение

Re: STM32 и USB (практика)

Вс сен 17, 2017 09:13:15

Оказалось всё дело в уровне оптимизации проекта. У меня изначально был 0 и поэтому ничего не работало (странно, почему так?).
Поставил Level 1 и заработало.


А у вас отладочная (debug) информация включена в проект или нет? USB не тот интерфейс, чтобы его можно было отлаживать по шагам в дебаггере. А включение отладочной информации замедляет работу программы. Возможно, при оптимизации O1 и выше вся отладочная информация из проекта выбрасывается и он начинает работать.

Re: STM32 и USB (практика)

Вс сен 17, 2017 09:37:29

Много раз запускал проекты с USB под отладкой и все нормально работало.

Re: STM32 и USB (практика)

Вс сен 17, 2017 11:00:46

Это вы просто не попадали на места с жёстко заданным таймаутом:

USB-совместимый хост предполагает, что все запросы будут обработаны в пределах максимального периода 5 секунд. Также определены более строгие лимиты времени для определенных запросов:

Standard Device request (стандартный запрос к устройству) без стадии данных должен быть завершен в течение 50 мс.
Standard Device request со стадией данных должен начать передавать данные не позже чем через 500 мс после запроса.
Каждый пакет данных должен быть отправлен в течение 500 мс после успешного завершения передачи предыдущего пакета. Стадия состояния должна быть завершена в течение 50 мс после передачи последнего пакета данных.
Команда SetAddress (которая содержит фазу данных) должна быть обработана и вернуть статус в течение 50 мс. Устройство тогда имеет 2 мс, чтобы изменить адрес прежде, чем будет послан следующий запрос.

Эти периоды времени ожидания являются весьма приемлемыми для даже самого медленного из устройств, но могут быть ограничением во время отладки. Невозможно обеспечить 50 мс для многих отладочных символов, отправляемых на скорости 9600 bps через асинхронный последовательный порт, или во внутрисхемных отладчиках/эмуляторах при выполнении программы по шагам или при остановке по точке останова для просмотра внутренних регистров и переменных. Поэтому USB требует специальной техники отладки в отличие от других проектов на микроконтроллерах.

http://microsin.net/programming/arm-wor ... part2.html
Ответить