Communication between DSP and PC

[shanzehq]

I am working on a pathological voice assessor device, using the STM32H747-DISCO development board. Currently focusing on sending a signal from the DSP to PC - there is also a separate connection for debugging from my Macbook which is plugged in to the ST-LinK Debugger port. I have found a data transfer example, so we have configured the USB-OTG port and it can now connect it to the PC. However, we are having different issue once it is connected to the PC. Essentially, this error occurs when looking at the connection in the Device Manager on the PC: 

 

"This device cannot start. (Code 10)", and "error code 000000000000A" which typically signifies a "device timeout" error but my Python program can recognize that there is a device connected and identify the correct VCOM. 

 

From our research, we have determined that this is most likely a driver issue on the PC end. We tried using STM provided drivers, however these only support Windows 7 and 8, while for windows 10 the recommendation is to simply use the Microsoft built in driver installers. Thus, using the STM provided drivers did not work even after we did try to use them. There is a small chance that this is a hardware issue as the USB OTG port is very loose and finicky when it comes to connectivity. 

 

Would anyone have any other recommendations to help the USB OTP connection. Alternatively should we use UART, SPI or I2C instead to bypass the driver issue?

[Pavel A.]

"error code 000000000000A" is same as "Code 10". 0xA is 10.

Basically this means that your firmware does not behave well. Fails some CDC requests or sends bad data. The initial USB enumeration was successful so Windows has detected the device and assigned it to the CDC driver.

Happy debugging.

 

 

[shanzehq]

Is this a result of the drivers? Would there be a solution to this? My guess is if the issue persists it wouldn't be sufficient to use the USB CDC communication protocol, right?

[Pavel A.]

CDC and its Windows driver emulate legacy COM ports and have certain  protocol overhead.

But don't just blame the in-box Windows drivers, they are very well tested against a lot of various hardware.

For a custom "application specific" device, a plain bulk pipe (and an interrupt pipe if needed) has minimal overhead. Windows has in-box driver named winusb for such devices, and usermode access library for it. The libusb for Windows also can be used with this.  

A problem with SPI or I2C is that a PC or Mac cannot connect to that without yet another adapter. STM32H7 has also 100 Mb/s Ethernet so you may want to use network instead of full-speed USB ( ~ 10 Mbit/s).