I am trying to build an HID keyboard. I got my STM32 MCU to recognize as a keyboard, but for some reason when I try to send the HID report (8 bytes) using Endpoint 1 in Interrupt mode. The host side doesn't get the data(key pressed) . Do I need to use the standard method Get_Report ?
I have also tried another implementation on a AT90USB1287. It works well but for some odd reason I must set the endpoint to 3 in order to get it working.
i am wondering if the USB HID keyboard protocol only looks at end point 3 when getting data?
The USB HID (keyboard) protocol uses the endpoint you specify in your USB descriptor. Look at the Endpoint address in the Endpoint descriptor.
Related
I am trying to get my com port working with my device and am having trouble doing so. I have already tested the serial output from my device using a RS-422 to USB convertor and data was being shown on my screen terminal flawlessly thorough /dev/ttyUSB0. My goal is to forgo the convertor and connect directly to my com port, /dev/ttyS0. The problem is when using screen to view my data on /dev/ttyS0 all I get is nonsensical data.
My device uses a slightly faster baud rate of 230400 so I though that might be an issue so I contacted the manufacturer but they stated the com port is capable of high speeds with an RS-422 protocol. I then followed up by doing getting a loopback cable and seeing if Tx matches Rx and it does. Ultimately, I am very confused as to why the RS-422 - USB convertor does the trick but when trying to simply use the serial port I get garbage data.
For clarity, My PC does indeed have a COM port to connect to serially. The bios settings let me pick if the port uses RS-422, RS-232, and RS-485. I have a gps connecting to my device and my device connects to my PC either through the COM port(does not work) or by usb with the convertor(does work). I expect a steady stream of positional data which I get only when using the convertor. When using the COM port I get random Char/numbers and unkown symbols(�). Only things I can think of is:
A. my COM port is broken(though it passed the loobback test)
B. Missing some sort of driver in order to run with a 230400 baud rate
C. Somehow the convertor is able to translate the ascii characters but the serial port cannot.
Hi I am trying to give a website direct on/off control of a usb relay on a chrome os device. In the past I just used some terminal scripts to run on start-up on a ubuntu device but chrome os is giving me a hard time making this work.
Based on the sample Linux code it looks like these devices are using an FTDI USB serial chip and support a very simple set of commands to turn the relays on and off. The FTDI chips are supported by ChromeOS and so you can use the Web Serial API to control the device like this:
let port = navigator.serial.requestPort();
await port.open({ baudRate: 9600 });
let writer = port.writable.getWriter();
writer.write(new Uint8Array([0xff, 0x01, 0x01]); // Turn relay on command.
await writer.close();
await port.close();
This is a very minimal example. You can improve this by passing a filter to requestPort() to select only the USB devices you want. You also don't need to request permission every time. You can call navigator.serial.getPorts() to get a list of ports that your site already has permission to access.
See https://web.dev/serial and https://wicg.github.io/serial for more information about how to use this API.
I'm trying to emulate a USB Keyboard with help of STM32 USB Device Library. The host here is not a Computer/ laptop, but a custom device to which a HID keyboard can be connected. I send data using API USBD_HID_SendReport(); but the host doesn't seem to recognize or read it by the time I write new data via same API. If I send same data for say 7 times the host reads it for 4 times only.
So is there anyway to know that the data is being read by USB Host from the EP Buffer?
Shall I change the bInterval in endpoint descriptor, what is the standard interval used in case of all keyboards?
P.S. The same data when sent to Computer or Laptop does gets read quickly by the host.
USBD_HID_SendReport only prepares the data for the next transmition when host requires one. It does not matter how many times you call this function. It will be send only as many times as host requested. The moment when it is send depends on the host only.
Device does not transmit anything without the host request
I am using a BeagleBone Black board (kernel 4.14.108-ti-r104) to create USB gadget using configfs/functionfs. I compose my gadget (using gadgettool) providing details about device configuration (function, vendor id, product id and ton of other params), run my userspace program that writes descriptors and strings to ep0 and connect the device to host. All works fine, I get BIND (when binding device to UDC) and ENABLE (when actually host is connected) events and my device can read from ep2 and write to ep1. Using wireshark I see the communication looks good, device and configuration descriptors as well as strings are exchanged.
The problem starts when I connect the device to another host. Unfortunately I have almost no control over that host, in particular I cannot run wireshark there, I don't even know the OS. The only thing I can do is to plug/unplug device, optionally see a message that device was detected and optionally a restart. What I see on the gadget side is that following BIND and ENABLE events I immediately get SUSPEND event and read on ep2 fails with 108 (ESHUTDOWN). Now the question is how to track the problem down.
I tried usbmon, but it seems it does not listen to traffic when device is in gadget mode. I have also seen https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/udc/trace.h file which seems to define some udc trace points, but I am not really sure how they can be used.
So the final question is simple: how do I get any information about traffic on USB bus having access only to gadget side? I don't need full trace, but al least some information which packets were exchanged would be super useful. Did it fail while exchanging device descriptors, configuration/interface/endpoint descriptors or strings or something totally different?
Small update:
The whole thing is about Android Open Accessory Protocol and I am trying to write a gadget that would connect to this accessory.
I have changed my gadget composition somewhat and now I know the gadget is being identified by host (it displays manufacturer/model) so I suppose the issue is not in device descriptor and strings. I have used two additional flags in descriptors (FUNCTIONFS_ALL_CTRL_RECIP | FUNCTIONFS_CONFIG0_SETUP) and when connecting to my computer I get setup event (request 51 as expected), but when connecting to my accessory I still get SUSPEND/ESHUTDOWN. This time though it looks like the time between ENABLE and SUSPEND is much greater (over 10 seconds) which looks to me as if the host send some message, but this message was not processed by my gadget and then the host timeout out and disabled usb device. Still don't know how to find out if the accessory sent anything to gadget and what it was...
I'm trying to set up a connection to a Bluetooth 4.0 LE device on Linux using the BlueZ 4.X DBus interface.
To test this I use the following command:
dbus-send --system --dest=org.bluez --print-reply /org/bluez/<PID of bluetoothd>/hci0 org.bluez.Adapter.CreateDevice string:<MAC of BT device>
This command seems to work most times, giving a result like:
method return sender=:1.238 -> dest=:1.262 reply_serial=2
object path "/org/bluez/9652/hci1/dev_BC_6A_29_26_C2_1C"
and enabling me to interact with the device DBus object.
However, starting from yesterday, this seems to fail very frequently returning the following error:
Error org.bluez.Error.Failed: Operation canceled
When debugging the bluetooth daemon, (using bluetoothd -n -d) I notice the following things when executing the method call:
bluetoothd[340]: src/adapter.c:create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/adapter.c:adapter_create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/device.c:device_create() Creating device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=2
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() Received 14 bytes from management socket
bluetoothd[340]: plugins/mgmtops.c:mgmt_connect_failed() hci0 BC:6A:29:26:C2:1C status 4
bluetoothd[340]: src/event.c:btd_event_conn_failed() status 0x04
bluetoothd[340]: src/device.c:device_remove() Removing device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=0
bluetoothd[340]: src/device.c:device_free() 0xb7ad8
As far as I can see, my Bluetooth dongle sends me an error event (status 4) when I try to connect to the device.
However, when I use hcitool ot gatttool to connect to the device, everything works perfectly.
I found that this happens mostly after I try to connect to the device using a different program (i.e cinnamon-settings), and cancel the connection prematurely. I also noticed this with other programs like bluetooth-properties on Angstrom.
My guess is that Bluez sends the wrong HCI commands to my bluetooth dongle in certain conditions. I think this is because the gui programs try to pair with the device instead of just connecting to it, which may cause BlueZ to think my device is a Bluetooth 2.0 device.
Thus far I seemed to be able to resolve this problem by connecting to my BT device using a gui application, waiting till it fails, and restarting my computer. However, the problem seems to reoccur occasionally, making this very painful.
I have seen this problem on systems running both BlueZ version 4.99 and 4.101.
Does anyone know how I can solve this correctly?
It seems like my predictions where more or less correct. After many hours of debugging the Bluetooth daemon I discovered that connecting to BT LE devices without a preliminary scan causes the daemon to try to connect to the device as a BR/EDR device. This is because the daemon's "internal cache" is filled with the EIR information at the time the device is discovered. If this information is not available when connecting to a LE device the CreateDevice method will fail.
A simple solution is to always make sure to discover devices before connecting to them.
The BlueZ 5 API introduction and porting guide also describes this problem, and how it is solved in BlueZ 5:
Bluetooth Low Energy essentially extended Bluetooth addresses with one extra bit, requiring one to always know whether an address is “random” or “public”. This caused issues with the BlueZ 4 API where the address was given to BlueZ in the CreateDevice and CreatePairedDevice calls. Since the parameter didn’t contain any of this extra random/public information bluetoothd had to maintain an internal cache to look up the necessary info. Another complication to the matter is that the BlueZ D-Bus API doesn’t differentiate between traditional BR/EDR devices and LE devices so there are essentially three possible address types: BR/EDR, LE public and LE random.