2016-03-24 05:11 AM
Having problems getting this to work. I discovered that optimisation may have been the cause of a couple of errors.
So, if I turn off all optimisation in SW4STM32 (eclipse IDE + gcc toolchain), I can get the F7 disco board to recognise what's plugged in, return VIDs and PIDs ok, and get as far as reporting ''Device not supporting CDC class'' which you can debug on and find that it's failed to init that class ok. I think it's failed to init that class (using USBH_CDC_InterfaceInit) because the USBH_FindInterface is returning 0xFF instead of 0. If I set USBH_FindInterface to always return 0, then a prolific chipset usb-serial adaptor will get as far as initialising, displaying ''press button to send data'' and then ''sending data ...'' but alas, no data on the scope. An FTDI device plugged in like this will say ''CDC class started'' but not ask to press the button, because the state machine in USBH_Process function is not handling a USBH_NOT_SUPPORTED status in the HOST_REQUEST state.Anyone got any advice for getting an STM32F7 Discovery USB Host CDC project working? #cdc #usb #host2016-03-25 05:09 AM
The USB-UART chips of FTDI, Prolific and SiLabs aren't CDC(-ACM) device. These chips expose vendor-specific class, unique for each product. Also, they have their own protocols (Vendor requests). Without knowing their protocols, your effort shouldn't take you anywhere.
To test the CDC host, Microchip MCP2200 exposes a composite device of CDC-ACM and HID. Also you may apply an CDC device example on another STM32 board.To customize the ST's CDC host, If you would like to implement custom protocol specific to a USB-UART chip, SiLabs protocol is fair simpler than others. They open their protocol in this appnote.https://www.silabs.com/Support%20Documents/TechnicalDocs/AN571.pdf
Try it first.For FTDI, Unlike SiLabs, FTDI don't open their protocol. You'll decipher the protocol using USB sniffer log and these source code for Linux.https://www.intra2net.com/en/developer/libftdi/
http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.c
or learn from implementation of other MCUhttp://processors.wiki.ti.com/index.php/Stellaris_-_USB_Host_FTDI
For Prolific, 1) Descriptors Prolific descriptors are simplified one of CDC-ACM; - Single interface with three endpoints (interrupt IN, bulk IN/OUT) - No extra class-specific descriptor 2) Bulk IN/OUT endpoints Prolific exchanges just data (without status) over bulk IN/OUT, like CDC-ACM 3) Modem Status Prolific carries status byte over the interrupt IN pipe, like CDC-ACM The status byte locates on the ninth byte of ''Notification'' bytes, like CDC-ACM Its bitmap is same as those of CDC-ACM, just with CTS extension.http://lxr.free-electrons.com/source/drivers/usb/serial/pl2303.c#L134
134 #define UART_DCD 0x01 135 #define UART_DSR 0x02 136 #define UART_BREAK_ERROR 0x04 137 #define UART_RING 0x08 138 #define UART_FRAME_ERROR 0x10 139 #define UART_PARITY_ERROR 0x20 140 #define UART_OVERRUN_ERROR 0x40 141 #define UART_CTS 0x80 CDC-ACM: UART State Bitmap of SERIAL_STATE notification D0 bRxCarrier - DCD D1 bTxCarrier - DSR D2 bBreak - break D3 bRingSignal - Ring D4 bFraming - framing error D5 bParity - parity error D6 bOverRun - overrun error D15..D7 - reserved 4) Vendor specific requests Prolific requires many vendor read/write at its start up. Refer to pl2303_startup() on the linux driver.http://lxr.free-electrons.com/source/drivers/usb/serial/pl2303.c#L220
Tsuneo2016-03-30 05:05 AM
Hello Tsuneo,
thanks for your advice and expertise. I got the CDC Host demo to work on the F7 Disco by using a 429i Disco board as a CDC device. Thanks for the tips on the Prolific driver, might give that a try. Unfortunately I think it's USB sniffer time as I'll be doing it for an FT230X, so I installed WireShark recently. I've been finding this out as I go along, so thanks again for the useful info,regards,Turboman