2014-12-04 3 views
0

Я пишу USB-устройство на стороне устройства, которое использует USB-модуль на процессоре Freescale Kinetis K20 ARM Cortex-M4. На стороне хоста я запускаю Arch на процессоре x64.Дескриптор устройства Linux read/64, ошибка 18

Проблема, с которой я сталкиваюсь, заключается в том, что я не могу заставить Linux читать дескриптор моего устройства. Мое устройство имеет одну конфигурацию с одним интерфейсом и без конечных точек (просто элемент управления). Мой дескриптор устройства выглядит так:

typedef struct { 
    uint8_t bLength; 
    uint8_t bDescriptorType; 
    uint16_t bcdUSB; 
    uint8_t bDeviceClass; 
    uint8_t bDeviceSubClass; 
    uint8_t bDeviceProtocol; 
    uint8_t bMaxPacketSize0; 
    uint16_t idVendor; 
    uint16_t idProduct; 
    uint16_t bcdDevice; 
    uint8_t iManufacturer; 
    uint8_t iProduct; 
    uint8_t iSerialNumber; 
    uint8_t bNumConfigurations; 
} dev_descriptor_t; 

static const dev_descriptor_t dev_descriptor = { 
    .bLength = 18, 
    .bDescriptorType = 1, 
    .bcdUSB = 0x0100, 
    .bDeviceClass = 0xff, 
    .bDeviceSubClass = 0x0, 
    .bDeviceProtocol = 0x0, 
    .bMaxPacketSize0 = ENDP0_SIZE, 
    .idVendor = 0x16c0, 
    .idProduct = 0x05dc, 
    .bcdDevice = 0x0001, 
    .iManufacturer = 0, 
    .iProduct = 0, 
    .iSerialNumber = 0, 
    .bNumConfigurations = 1 
}; 

Предполагая, что процессор считывает байты, начиная с bLength я думаю, что этот дескриптор будет работать (я соответствующие конфигурации интерфейсов и дескрипторы, но даже не получают, что далеко).

Ошибки я получаю следующим образом:

usb 4-1.4: device descriptor read/64, error 18 
...repeated 4 times 
usb 4-1.4: device descriptor read/8, error -75 
..repeated 4 times 
usb 4-1-port4: unable to enumerate USB device 

мне удалось найти список кодов ошибок и -75 является EOVERFLOW, который имеет смысл, так как мой дескриптор не поместилась бы внутри 8 байт для чтения , Тот, что на самом деле меня смущает ошибка 18.

Мой вопрос:

Что такое ошибка 18 и каковы его причины?

Просто, чтобы быть ясным: мой вопрос заключается не в том, чтобы заставить USB-модуль работать на микроконтроллере Kinetis (хотя любые подсказки и опыт были бы оценены) ... о том, как узнать, что означает этот код ошибки, и диагностировать проблема, которая его вызывает.

Ошибка -18 (обратите внимание на отрицательный результат) - это EXDEV (сшивающее устройство), которое не имеет для меня никакого смысла, потому что я не знаю, что это значит.


Примечание 1

Я знаю, что это не аппаратная проблема с модулем USB, так как микроконтроллер является частью Teensy 3.1 совета, и я использовал его модуль USB в прошлых проектах, но используя предоставленный драйвер, который поставляется вместе с библиотекой Teensyduino. Я пишу свой собственный, чтобы лучше понять модуль.

Примечание 2

Если его полезно знать, микроконтроллер получает команду, которая будет присвоен адрес и, кажется, правильно реагировать (т.е. нет «не принимает адрес» ошибки в моем журнале ... Я уже проработал через них). Помимо этого и команды get descriptor, похоже, что он не получает никаких дополнительных команд.

ответ

0

18 здесь нет ошибки. Обратите внимание, что это положительное число, а все коды ошибок преобразуются в отрицательные числа в ядре Linux.

Здесь 18 - это возвращаемое значение usb_control_msg(), которое возвращает длину дескриптора устройства в случае успеха. Таким образом, это поле bLength в дескрипторе устройства, которое равно 18.

Проблема заключается в поле bMaxPacketSize0. Я не знаю, что такое ENDP0_SIZE, но ядро ​​usb принимает только следующие значения: 8, 16, 32, 64, 255. Если это не соответствует, usb_control_msg() считается ошибкой и сообщает об ошибке.

Проверьте hub_port_init() в драйверах/usb/core/hub.c.Поток кода должен быть четким.

+0

Оказывается, это был 'bMaxPacketSize0', но не в том, что он был установлен неправильно (мой установлен на 64). Прочитав код, казалось, что он не получал никаких данных с моего устройства, когда ожидал 18 байт. Я пометил свой дескриптор 'struct' как' const', который по какой-то причине помещал его в недоступную область памяти (вероятно, вспышку). Удаление 'const' позволило устройству фактически отправить его дескриптор, который устранил проблему. Спасибо за отзыв о 'drivers/usb/core'! –

Смежные вопросы