From: Atton_666 <fla...@ho...> - 2012-06-28 14:43:35
|
Hi everybody, I develop an application on Windows 7 64bits with Qt Creator. I use libusb win 32 in order to communicate with a STM32 µc. I can find my device after install a driver with inf-wizard. I can open connection with this device but i can't use bulk_read/write. Here is a part of my code: #define VENDOR 0x0483 #define PRODUCT 0x3748 #define EP_IN 0x81 #define EP_OUT 0x02 #define BUF_SIZE 64 m_testUSB->clear(); //Effacement du texte précédent. int ret; char buffer[BUF_SIZE]; //Définition de la taille du Buffer permettant l'échange d'instructions //entre le périphérique USB et le PC struct usb_bus *busses = new usb_bus(); // Création de la structure busses permettant d'obtenir des informations sur les bus du PC usb_init(); // Initialisation de la librairie. Cette fonction doit être appelée avant tout autre fonction de libUSB m_testUSB->append("le nombre de bus = " + QString().setNum(usb_find_busses())); //Récupération du nombre de bus depuis le dernier appel à cette fonction m_testUSB->append("le nombre d'appareil = " + QString().setNum(usb_find_devices())); //Récupération du nombre de périphérique (Branché/Débranché) depuis le dernier appel à cette fonction busses = usb_get_busses(); //récupération de la liste des bus usb // Parcours tous les bus for (struct usb_bus *bus = busses; bus; bus = bus->next) { int k = 0; //Compteur d'appareil attendu // Parcours tous les appareils afin d'identifier l'appareil concerné for (struct usb_device *dev = bus->devices; dev; dev = dev->next) { // Teste si le périférique détecté est bien celui qui possède les PID VID indiqués par PRODUCT et VENDOR if( (dev->descriptor.idVendor == VENDOR) && (dev->descriptor.idProduct == PRODUCT) ) { k++; m_testUSB->append("CLE DETECTEE"); // Ouverture de l'appareil struct usb_dev_handle *devHandle ; devHandle = usb_open(dev); if (dev == NULL) { m_testUSB->append("Erreur a l'ouverture."); } else { // Set la configuration active if(usb_set_configuration(devHandle, 1)>=0) { m_testUSB->append("Configuration 1 réussie"); } else { m_testUSB->append("Configuration 1 ratée"); usb_close(devHandle); } //Demande d'interface avec le périphérique if(usb_claim_interface(devHandle, 0)>=0) { m_testUSB->append("Demande d'une interface et process"); } else { m_testUSB->append("Impossible d'ouvrir l'interface"); } if(usb_set_altinterface(devHandle,0)==0) { m_testUSB->append("Config interface OK"); } else { m_testUSB->append("Config interface Ratée"); } //Initialise les configurations des endpoints if(usb_clear_halt(devHandle, EP_OUT)>=0) { m_testUSB->append("usb clear halt ep out OK"); } if(usb_clear_halt(devHandle, EP_IN)>=0) { m_testUSB->append("usb clear halt ep in OK"); } buffer[0]=0x00; //Ecriture sur le périphérique ret = usb_bulk_write(devHandle, EP_OUT, buffer, sizeof(buffer), 500); if(ret) { m_testUSB->append("usb_interrupt_write OK"); } if( (ret = usb_bulk_write( devHandle, EP_OUT, buffer, sizeof(buffer), 500 )) < 0 ) { m_testUSB->append( QString( "usb_interrupt_write KO : %1" ).arg( usb_strerror() ) ); } else { m_testUSB->append( QString( "usb_interrupt_write OK : %1 écrits" ).arg( ret ) ); } // if(ret>0) // { // m_testUSB->append("usb_interrupt_write test OK"); // m_testUSB->append("Emis : " ); // m_testUSB->append(buffer); // } // else // { // m_testUSB->append("Erreur écriture: "); // m_testUSB->append(usb_strerror()); // } // Fermeture de l'appareil usb_close(devHandle); } } } if(k==0) // Si le périphérique voulu n'est pas détecté on affiche le message ci-dessous m_testUSB->append("LA CLE N'EST PAS DETECTEE"); Here is my libusb test's result: DLL version: 1.2.6.0 Driver version: 1.2.6.0 bus/device idVendor/idProduct bus-0/\\.\libusb0-0001--0x0483-0x3748 0483/3748 - Manufacturer : STMicroelectronics - Product : STM32 STLink - Serial Number: VÿjIpST(%‡ bLength: 18 bDescriptorType: 01h bcdUSB: 0200h bDeviceClass: 00h bDeviceSubClass: 00h bDeviceProtocol: 00h bMaxPacketSize0: 40h idVendor: 0483h idProduct: 3748h bcdDevice: 0100h iManufacturer: 1 iProduct: 2 iSerialNumber: 3 bNumConfigurations: 1 wTotalLength: 39 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 80h MaxPower: 50 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 3 bInterfaceClass: 255 bInterfaceSubClass: 255 bInterfaceProtocol: 255 iInterface: 4 bEndpointAddress: 81h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 02h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 83h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 Here application's messages: le nombre de bus = 0 le nombre d'appareil = 0 CLE DETECTEE Configuration 1 réussie Demande d'une interface et process Config interface OK usb_interrupt_write OK usb_interrupt_write KO : libusb0-dll:err [_usb_reap_async] timeout error And to finish reports of out application: libusb0-dll:[os_init] dll version: 1.2.6.0 libusb0-dll:[os_init] driver version: 1.2.6.0 libusb0-dll:[os_find_busses] found bus-0 libusb0-dll:[os_find_devices] found \\.\libusb0-0001--0x0483-0x3748 on bus-0 libusb0-dll:err [_usb_reap_async] reaping request failed, win error: Un périphérique attaché au système ne fonctionne pas correctement. libusb0-dll:err [_usb_reap_async] timeout error I hope that someone is able to fix my problem ;) Best Regards. -- View this message in context: http://libusb.6.n5.nabble.com/Timeout-Error-with-libUSB-Win-32-tp5710113.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
From: alex_f <ale...@gm...> - 2012-10-04 07:56:00
|
Hi Atton_666, I'm currently facing exactly the same problems with also exactly the same device (st-link debugger). Currently I've found out that this only happens with bulk read requests that are a multiple of 64 bytes or with really large buffers >1500 bytes, but I've still got not clue why this happens. To make things worse, I've looked into the communication with the original driver and there its working, i.e. I saw a mem read request for 64 bytes. The very same request fails for me. By the way, I've tried it on both, Windows and Linux with the same behavior. As a suboptimal workaround I'm now checking for multiples of 64 bytes when doing mem reads and divide it into two requests. Have you got any further by now? Thanks, Alex -- View this message in context: http://libusb.6.n5.nabble.com/Timeout-Error-with-libUSB-Win-32-tp5710113p5710727.html Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com. |
From: Xiaofan C. <xia...@gm...> - 2012-10-05 01:44:46
|
On Thu, Jun 28, 2012 at 10:43 PM, Atton_666 <fla...@ho...> wrote: > Hi everybody, > > I develop an application on Windows 7 64bits with Qt Creator. I use libusb > win 32 in order to communicate with a STM32 µc. I can find my device after > install a driver with inf-wizard. I can open connection with this device but > i can't use bulk_read/write. > > Here is a part of my code: > > #define VENDOR 0x0483 > #define PRODUCT 0x3748 > > > bus/device idVendor/idProduct > bus-0/\\.\libusb0-0001--0x0483-0x3748 0483/3748 > - Manufacturer : STMicroelectronics > - Product : STM32 STLink Is this ST-Link V2 which uses the WinUSB driver from ST? ST-Link V1 uses the mass storage driver. Just wondering why you want to libusb-win32 for ST-Link? If you use OpenOCD, it already works with ST-Link V1/V2 under Windows. For V2, you can use the ST WinUSB based driver. For V1, you can replace the original driver with WinUSB or you can even use the libusb-win32 filter driver if you use libusbx-1.0.13 or 1.0.14. I provide an OpenOCD Windows binary here. http://code.google.com/p/picusb/downloads/detail?name=openocd_0.6.0_mingw32.zip > Here application's messages: > > le nombre de bus = 0 > le nombre d'appareil = 0 > CLE DETECTEE > Configuration 1 réussie > Demande d'une interface et process > Config interface OK > usb_interrupt_write OK > usb_interrupt_write KO : libusb0-dll:err [_usb_reap_async] timeout error > > And to finish reports of out application: > > libusb0-dll:[os_init] dll version: 1.2.6.0 > libusb0-dll:[os_init] driver version: 1.2.6.0 > libusb0-dll:[os_find_busses] found bus-0 > libusb0-dll:[os_find_devices] found \\.\libusb0-0001--0x0483-0x3748 on bus-0 > libusb0-dll:err [_usb_reap_async] reaping request failed, win error: Un > périphérique attaché au système ne fonctionne pas correctement. > > libusb0-dll:err [_usb_reap_async] timeout error > > I hope that someone is able to fix my problem ;) You may want to install the debug version of the driver and use debugview to post the error message. It will give your more details. 1) Debug version of libusb-win32 http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/ Download libusb-win32-bin-debug-1.2.6.0.zip Use the inf-wizard inside the archive to reinstall the driver for your device. Or just copy 'bin\x86\libusb0.sys' to 'windows\system32\drivers\libusb0.sys' (overwrite the original file), disconnect your USB device and re-boot. 2) Debugview: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx You need to run debugview as admin and turn on all the option under the capture menu. 3) Then connect your USB device and run your program. You should now have debug logs and please post the debug logs in your reply. -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2012-10-05 01:47:50
|
On Thu, Oct 4, 2012 at 3:55 PM, alex_f <ale...@gm...> wrote: > I'm currently facing exactly the same problems with also exactly the same > device (st-link debugger). Currently I've found out that this only happens > with bulk read requests that are a multiple of 64 bytes or with really large > buffers >1500 bytes, but I've still got not clue why this happens. To make > things worse, I've looked into the communication with the original driver > and there its working, i.e. I saw a mem read request for 64 bytes. The very > same request fails for me. > > By the way, I've tried it on both, Windows and Linux with the same behavior. > As a suboptimal workaround I'm now checking for multiples of 64 bytes when > doing mem reads and divide it into two requests. It could be that you need to manually send out ZLP (zero length package) to terminate the transfer. What is the purpose of using libusb-win32 with your ST-Link? Most of the program uses libusb-1.0 API with ST-Link, including OpenOCD and this one. https://github.com/texane/stlink -- Xiaofan |
From: Alexander F. <ale...@gm...> - 2012-10-05 09:31:13
|
On 2012-10-05 03:47, Xiaofan Chen wrote: > It could be that you need to manually send out ZLP (zero length package) > to terminate the transfer. Do you mean from the device to the host? As the firmware on the device is fixed, I'd not be able to do that. > What is the purpose of using libusb-win32 with your ST-Link? In short, pure interest in controlling the device by myself via the DAP interface. In a bit more words, I've started with the embedded R-Link on my Primer2 that is only wired to the serial wire interface and not to the JTAG any more. Therefore, OpenOCD didn't work (that time, didn't check lately). As I'm using both Windows and Linux I wanted to have a single solution. Being an Eclipse and Scala users as well, I started creating my own GDB server implementation using the LibUSBJava library, which was based on libusb-0.1 at that time. Idea behind was to have a nice view in Eclipse where I could access the registers and the memory directly once a device is attached an would not need to run GDB for that, i.e. separating the control of the device from the GDB protocol. I'd also like to access the tracing interface, which to my knowledge is not done today by the solutions you mention below. As for the Primer2, I stopped some time back, but was at least able to access the memory (+ memory mapped registers). Now I'm playing around with the STM32F4discovery board, which contains an on-board st-link v2. > Most of the program uses libusb-1.0 API with ST-Link, including OpenOCD > and this one. > https://github.com/texane/stlink > Thanks, and especially https://github.com/texane/stlink was a good source of information. br Alex |
From: Xiaofan C. <xia...@gm...> - 2012-10-09 05:04:34
|
On Fri, Oct 5, 2012 at 5:30 PM, Alexander Fried <ale...@gm...> wrote: > On 2012-10-05 03:47, Xiaofan Chen wrote: > It could be that you need to manually send out ZLP (zero length package) > to terminate the transfer. > > Do you mean from the device to the host? As the firmware on the device is > fixed, I'd not be able to do that. I see. Have you updated the firmware to the latest version? On the other hand, it may be possible to do this from the host side as well. Reference: http://www.libusb.org/ticket/6 -- Xiaofan |
From: Alexander F. <ale...@gm...> - 2012-10-27 08:12:50
|
2012/10/9 Xiaofan Chen <xia...@gm...> > On Fri, Oct 5, 2012 at 5:30 PM, Alexander Fried > <ale...@gm...> wrote: > > On 2012-10-05 03:47, Xiaofan Chen wrote: > > It could be that you need to manually send out ZLP (zero length package) > > to terminate the transfer. > > > > Do you mean from the device to the host? As the firmware on the device is > > fixed, I'd not be able to do that. > > I see. Have you updated the firmware to the latest version? > Yes, firmware is on latest version and from what I found out by now, it simply requires to know how much data will be transferred from device to the host. No ZLP will be send by the device, but setting the length correctly will work. As a side note I've found out that setting a higher length on Linux will time out but the data is still received, whereas on Windows (with winusb as backend), the timeout happens as well, but zero bytes are transferred. Is this to be expected? br Alex |
From: Xiaofan C. <xia...@gm...> - 2012-10-28 03:08:06
|
On Sat, Oct 27, 2012 at 4:12 PM, Alexander Fried <ale...@gm...> wrote: > Yes, firmware is on latest version and from what I found out by now, it > simply requires to know how much data will be transferred from device to the > host. No ZLP will be send by the device, but setting the length correctly > will work. > > As a side note I've found out that setting a higher length on Linux will > time out but the data is still received, whereas on Windows (with winusb as > backend), the timeout happens as well, but zero bytes are transferred. Is > this to be expected? I am not sure. Probably you can ask in the libusbx mailing list to see if that is normal or not. Make sure you use the latest libusbx release before posting the problem and debug log there. https://lists.sourceforge.net/lists/listinfo/libusbx-devel -- Xiaofan |