Dji Bulk Interface Driver

[David]

Thestandard DFU driver under the provided windows_drivers folder worked for this setup, but I had to adjust the bulk device driver INF file in order to get Windows to recognize it as the driver for this device. This causes an "unsigned driver" error that is rather painful to ignore in Windows 8 and 10. Is there a signed driver example of the USB Bulk Device as device 0 in a composite device setup? Or is this something that must be customized and signed on our end?

John Collins0 said:but I had to adjust the bulk device driver INF file in order to get Windows to recognize it as the driver for this device. This causes an "unsigned driver" error that is rather painful to ignore in Windows 8 and 10.

I tried plugging in the changes I noticed from this example to my existing project (using the TivaWare libraries from v2.1.0.12573). I got everything to load up properly, but the devices show up as two WinUsb Devices under the Universal Serial Bus Devices (This seems to be Windows 7 specific). I can't connect to the USB handle from my interface software on the PC and the dfuprog -e doesn't show anything either.

Thanks for this! After updating the ARM Compiler to v5.2 and using the TivaWare C Series v2.1.2.111 files, I was able to get the example working. From here, I was able to add it to one of our existing builds. We are testing this out now to see if it will work for our solution.

I am currently attempting to incorporate your solution into an existing project we have that uses 3 separate interface, only one of which supports the MS OS Descriptor, through the USB Bulk device type, the others use the standard CDC and HID interfaces.

I've pulled in your usbdenum_mod3.c file into the project and verified that the MSOSdescHandleStringRequest() routine is getting called, but i never receive a GET_DESCRIPTOR request form the Windows host at string index 0xEE.

This project is linked to an unmodified version of usblib.lib. Is it possible that the enumeration code in the usblib.lib is stalling the string request at offset 0xEE before it is able to be processed by the modified version of the USBDReadAndDispatchRequest() routine in usbdenum_mod3.c? Any other explanation for why I am not seeing the Get Descriptor request at index 0xEE?

I have been working with the example usbserialdevice. When I use this example with my development board using a TM4C129NDCPT, it works great. The troubles I'm having is migrating that understanding to my other projects. When the USB installs from my custom project, I get an error in my device manager "A request for the USB device descriptor failed." Additionally, I noticed that in my details under the device, under device instance path, my VID and serial number are not what are in my custom project.

I am a beginner to Linux drivers and I started with writing an application for a cdc-acm based USB device in linux. Therefore, I have used the cdc_acm driver. The USB device that I am using has 2 Bulk endpoints (read and write) and one interrupts endpoint.

If I write a data to trigger a USB functionality into the ttyACM0 file, will the data get sent through bulk out endpoint? Or how should I send the data to the bulk endpoint directly from user space. Should I write any supporting driver in kernel space?Similarly, how do I read the data from interrupt endpoint in the userspace?

There is no need to write a kernel space driver. You can open /dev/ttyACM0 with the open system call, set parameters for it using termios (optional), and then use the read and write system calls to read and write bulk data from your device. These system calls are easiest to access from C and C++, but most languages have a library you can use to access serial ports.

The Linux serial port interface abstracts away all details about USB, endpoints, and bulk transfers, so you can use a simpler, more abstract API to communicate with the serial port. In fact, you can use the same code on any type of serial port, regardless of which kernel driver implements the serial port. It might help you to search the Internet for things like "linux serial port programming" or "posix serial port programming" to understand more about how to do this.

If you really are curious about how the Linux CDC ACM driver works, and how it converts a write system call into the corresponding USB transfer, you can read the source of the cdc-acm driver. However, that is way beyond what you need to do to simply use a serial port.

Before I started I made sure that I can actually talk to the Jlink using Jlink commander. It is confirmed by this. My Device manager looks like this There are two entries that appear when I plug in the Jlink: CDC and BULK I open Zadiq, and use...

This link (Error while flashing SoftDevice - J-Link EDU Issue #228 sandeepmistry/arduino-nRF5 GitHub) says it was solved by reinstalling JLink drivers and then using Zadig again with WinUSB, and that the Bulk interface is the right one to replace. This thread ([OpenOCD-user] JLink works on 0.4.0, but not on 0.6.1 OpenOCD - Open On-Chip Debugger) says that libusb-win32 drivers may also work.

Hi Mik,

I see you tried a lot of options to get it working. I would try to change the frequency reasonable numbers. 20 kHz may be too slow for some reason (maybe some timeout would occur). Go to 1000 kHz, I was running on 5000 kHz fine with some 10 cm long cables.

Yourigh,

Thank you so much for your response, and the useful screen shots. . (5th day on this now) Yup, refreshed FW in jlink, I tried all the options you mention but to be sure I just ran through a bunch of speeds again, hunting around at various kHz. I should mention that I can get it to work under eclipse.

I have for a long time been wanting to do a Custom USB class driver on the RT106x devices. I have been put down by the, seemingly, complex structure of the NXP USB example code. While I still don't think the samples in the SDK are "the best" out there, they do seem to work, and at least provide a starting point. Several people here have been looking for an implementation of a Custom USB class device, myself including. I have a Bulk device running on a number of NXP processors (LPC2148, LPC2458, LPC1788, LPC54628 etc) and I wanted to have the same running on a RT1064.

Now, there is ABSOLUTELY NO GUARANTEE that the code is correct, the only guarantee I can give is that there is probably something (or a lot) that could be made much better/smarter/faster. But, this at least works for me as it is. I will continue testing and fixing stuff, when I find something that can be improved, I will post it in this thread.

You are absolutely free to use the code in any way you see fit (as long as you follow the rules/guidelines from NXP). However, if you spot something bad/wrong etc, PLEASE let us know so we all benefit from this!

This device creates a Custom USB class using VID=0xFFFF, PID=0x4712 and Class=0xFF (Vendor specific)

The USB class has one interface (interface 0) and one configuration (configuration 1).

It has 4 endpoints, 1 OUT and 3 IN endpoints. In practice, it uses the OUT and one of the IN endpoints as a "channel" for a request/response type command interface. The two last IN endpoints are used for sending log messages and wireshark compatible frames (when the target device has a TCP/IP stack embedded that it wants to send debug traffic from).

Tested on USB0 on i.MXRT1064. I'm not sure how much needs to be done to have it work on USB1, I have tried to leave the code that was in the CDC sample from NXP, but no guarantee!

I'm the STM32F207 user, as title mentioned, I have a trouble when configure the usb packet size from the default 64 bytes to 256 bytes. The problem is that my usb device may not be able to connect with all PC host(there are about 10 PC with different version Windows for test) when I configured it as 256 bytes for bulk in/out endpoints, it's strange that my usb device couldn't connect with two PC host which were not properly installed the usb driver for my usb device, but it just worked fine on all other PC hosts, and If I configured my usb device with 64 bytes packet size, it worked fine on all PC host.

The issue was happened during the USB initialization, as PC host will request the Device Descriptor, Configuration Descriptor etc..., when PC is requesting to Set Configuration Descriptor, my usb device was received that request and set the configurations accordingly and then respond a 'Zero Length Packet' as the ACK packet to the Host, but after this ACK packet was issued, PC host stopped to request the last Configuration Descriptors.

Are you using USB_OTG_FS or USB_OTG_HS with internal FS PHY? If either is the case, you cannot increase the packet size over 64 bytes, as it is the maximum allowed for a Full Speed device. This conflict is what the smarter USB drivers may recognize from the configuration descriptor, and reject connection to the device. Even if the device is accepted by the driver, the transfers over these incorrectly configured endpoints will not be operational.

And about the 256 bytes packet size, is it normal that my usb device which the bulk in/out endpoints were configured as 256 bytes packet size can normally communicate with some PC hosts, as I have tried a to transact between Host and Device with about 1K data bytes and the result looks fine?

The fact that this packet size works for you probably has something to do with the fact that the USB OTG IP used in STM32 devices is designed for FS and HS operation as well, and might be prepared to handle data size up to HS packet size limit (512 bytes) when in FS mode.

A USB bulk endpoint can transfer large amounts of data. Bulk transfers are reliable that allow hardware error detection, and involves limited number of retries in the hardware. For transfers to bulk endpoints, bandwidth is not reserved on the bus. When there are multiple transfer requests that target different types of endpoints, the controller first schedules transfers for time critical data, such as isochronous and interrupt packets. Only if there is unused bandwidth available on the bus, the controller schedules bulk transfers. Where there is no other significant traffic on the bus, bulk transfer can be fast. However, when the bus is busy with other transfers, bulk data can wait indefinitely.

3a8082e126