I am developing a custom USB HID device with both IN and OUT interrupt endpoints of 64 bytes length each. There are 2 reports (one with report ID 1 and other with report ID 2) with report count of 63 bytes each. When the PC app developed in VC++ sends a 64 byte buffer using WriteFile(), I receive the entire buffer properly at the device on the OUT interrupt endpoint. But when I send a 64 byte buffer from the device to the PC on the IN endpoint, the ReadFile() returns with a value of 4 (timeout). This happens only 2 times when the device is plugged in. After that everything works fine and the PC reads the 64 bytes sent by the device properly.
I am using USBlyzer tool to sniff the USB bus traffic. That software shows that for the first two times the device sends a 64 byte buffer on the interrupt IN endpoint, but it too is not able to show the data in it. And the 3rd time onwards, everything works magically, both PC application and USBlyzer receive and display the 64 bytes buffer contents on the screen.
I am not sure where exactly the problem lies, is it on the PC side code or in the device firmware? Please share your thoughts.
Related
I have a web app which uses web bluetooth api. GATT server is running on STM32 microcontroller. Web app works good on Android devices, but it keeps disconnecting on Windows 11 in a Chrome browser. I used WireShark to track BLE packets. The disconnection reason is following: "Remote user terminated connection (0x13)".
I have tested web bluetooth on the same windows device with a different GATT server running on my Android phone. In this case it worked well. What can be an issue?
The peripheral is sending a malformed GATT packet.
Packet 163, Read By Group Response, contains 156 bytes of Attribute Protocol data. It contains a list of services, each is 20 bytes, consisting of (start handle, end handle, service uuid). The list contains 7 valid entries. After that follows an entry which is truncated to 14 bytes. That entry should not be present in the list since it does not fit. So, it seems the GATT server software running on the peripheral is buggy.
The client is supposed to continue the search by sending a new Read By Group Request containing a start handle that is +1 of the last retrieved end handle.
I am using a Zebra DS457 Scanner to read bar and qr codes via COM-Port (RS232). In my test evironment I used a MSI terminal with Win10 and it worked on the real COM-Port without any problems. But on other devices (Win10 and Win7) there are some issues that the software trigger does not come through and the read information do not get sent back to the computer. When I am using a USB to RS232 FTDI adapter I have no issues at all. But why? First I thought it is Win10 and the legacy support could be better, but the adapter is on all devices better and faster. How is this possible? Maybe a driver specific thing? I am using this adapter link to conrad.de.
An FTDI serial port will impose a minimum latency between the time a character arrives over the wire and when an application can see it, and between the time an application wants to send something and the time it goes over a wire. On older devices, these latencies were a minimum of 1ms each, but I think some newer high speed devices have reduced them to 125us. Further, data which arrives at just the wrong speed sometimes ends up with hundreds of milliseconds of additional latency, for reasons I don't quite understand.
On the other hand, an FTDI device can buffer 256 bytes of data from the wire, or 128 bytes of data from the USB port to be sent over the wire, and process RTS/CTS handshaking, without any software intervention--abilities which are lacking in the UART chips used by PC serial ports. If software gives 128 bytes to an FTDI device, it will start sending it until the remote device deasserts its handshake line, whereupon the FTDI device will stop sending as soon as the current byte is complete; it will then resume transmission as soon as the remote device reasserts handshake. If an FTDI device receives enough data over the wire that its UART would be in danger of overflowing, it will automatically deassert its handshake output without requiring any software intervention. The UART used in PC serial port, by contrast, requires a fast interrupt handler to control or respond to the handshake wires. If an interrupt handler maintains a 4096-byte buffer, it may deassert the handshake wire once that buffer is 75% full, but nothing would deassert the handshake wire if the buffer is less than 75% full and 17 bytes arrive over the wire in quick succession before the UART interrupt handler. Worse, if transmit buffering is enabled, and the PC has fed 16 bytes to the UART for transmission when the remote device deasserts its handshake line, those 16 bytes will be sent out whether or not the remote device is ready to receive them (and based upon the handshake wire, it very well might not be).
Thus, some applications can work much better with an FTDI UART, and some much better with an actual serial port.
I have probably a very simple question.
When I initialize the port in Windows 10 the control message sent to USB device is incomplete. Windows sends the speed, but all other parameters are zeros (ie parity, nbits etc). I have checked the raw data received by the endpoint, I have also sniffed the communication on the cable - and Windows does not send this data.
Is this the standard virtual serial windows driver issue?
I have problem with communication via USB CDC with Windows. On Linux or Mac everything work good.
So, when I try to connect to my COM port I get notification from PUTTY "Unable to open communication to COM2. Unable to configure port.
It is my own device based on Rx63n uC, I transmit in FullSpeed standard, packet in size less than 64 bytes. I'm used 2 endpoints for bulk transfer IN/OUT.
In USBLyzer I got information thatSTALL packet is received from my device after error (USBD_STATUS_CANCELED).
I used driver from Windows 10 usbser.sys.
Any ideas what is wrong?
I forgot to add that in USBLyzer I see a lot of my packets, and after transferred some data it generate error as above.
I am attempting to communicate with a custom USB device through windows using libusbx. I have the WinUSB driver installed for the device and am able to get some communication to happen. It's just not operating as I expect.
I am trying to get some basic two way communication happening essentially from the PC I send a single byte and expect some number of bytes back. Currently if I reset the device and run my program that sends a byte, I only receive a single byte back. If I re-run my program, I get just the next byte back. This happens a few more times until eventually I receive what I expect.
For example:
PC sends an 'a'
the expected output is
buffer[0]=3c
buffer[1]=6c
buffer[2]=0
buffer[3]=3e
What I actually get is:
//First try
buffer[0]=3c
//Second Try
buffer[0]=6c
//Third Try
buffer[0]=0
buffer[1]=3e
//Fourth+ tries
buffer[0]=3c
buffer[1]=6c
buffer[2]=0
buffer[3]=3e
When I test the USB device over a com port using serial communication, everything operates as expected.
Here is a pastebin of the code being ran:
http://pastebin.com/bQtyS6vq
Has anyone experienced similar problems or have any suggestions for a fix?