search

florentbr / OWON-VDS1022

Unofficial release for the OWON VDS1022/I Oscilloscope
249 stars 43 forks source link

USBError on API example #54

Closed vfperri88 closed 1 year ago

vfperri88 commented 2 years ago

Hi, I'm trying to run the examples, but it throws this error in Windows 10: "USBError: [Errno None] b'libusb0-dll:err [clear_halt] could not clear halt, ep 0x03, win error: El par\xe1metro no es correcto.\r\n'". And in Ubuntu 22.04 I have also a similar issue. The problem is always in the same point:

File c:\Osciloscopio\OWON-VDS1022\api\python\vds1022\vds1022.py:1189, in VDS1022._connect(self) 1187 handle = self._handle = usb.open_device(dev) 1188 usb.claim_interface(handle, USB_INTERFACE) -> 1189 usb.clear_halt(handle, USB_EP_WRITE) 1190 usb.clear_halt(handle, USB_EP_READ) 1192 if self._send(CMD.GET_MACHINE, CMD.V) == 1: # 0:Error 1:VDS1022 3:VDS2052

Is anyone having the same problem? Thanks a lot,

Víctor

florentbr commented 2 years ago

That's unexpected. The call to usb.clear_halt shouldn't fail even though it's not required. Anyway I committed the wrong version of vds1022.py in release 1.1.3 . Try this modified version and let me know if it works with your device: https://github.com/florentbr/OWON-VDS1022/tree/fix-api/api/python

vfperri88 commented 2 years ago

Tanks a lot for the quick feedback, I'm still having some troubles in Windows and Linux.

Windows log:

Traceback (most recent call last): File "c:\Perri\Osciloscopio\Ejemplos\OsciloscopioTestv01.py", line 3, in dev = VDS1022() File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1096, in init if not self._connect(): File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1207, in _connect if self._send(CMD.GET_MACHINE, CMD.V) == 1: # 0:Error 1:VDS1022 3:VDS2052 File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1258, in _send self._on_usb_err(ex, cmd, arg) File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1264, in _on_usb_err raise ex File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1256, in _send return self._bulk_send(cmd, arg) File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1245, in _bulk_send self._bulk_write(cmd.pack(arg)) File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\vds1022\vds1022.py", line 1233, in _bulk_write self._usb.bulk_write(self._handle, USB_EP_WRITE, USB_INTERFACE, buffer, USB_TIMEOUT) File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb0.py", line 545, in bulk_write return self.__write(_lib.usb_bulk_write, File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb0.py", line 681, in __write return int(_check(fn( File "C:\Users\vfperri\AppData\Local\Programs\Python\Python310\lib\site-packages\usb\backend\libusb0.py", line 447, in _check raise USBError(errmsg, ret) usb.core.USBError: [Errno None] b'libusb0-dll:err [submit_async] submitting request failed, win error: El par\xe1metro no es correcto.\r\n'

Linux log:

Traceback (most recent call last): File "/home/vfperri/Documentos/Electrónica/Osciloscopio/Ejemplos/testOsciloscopiov01.py", line 3, in dev = VDS1022() File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1096, in init if not self._connect(): File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1207, in _connect if self._send(CMD.GET_MACHINE, CMD.V) == 1: # 0:Error 1:VDS1022 3:VDS2052 File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1258, in _send self._on_usb_err(ex, cmd, arg) File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1264, in _on_usb_err raise ex File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1256, in _send return self._bulk_send(cmd, arg) File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1245, in _bulk_send self._bulk_write(cmd.pack(arg)) File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1233, in _bulk_write self._usb.bulk_write(self._handle, USB_EP_WRITE, USB_INTERFACE, buffer, USB_TIMEOUT) File "/home/vfperri/.local/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write return self.write(self.lib.libusb_bulk_transfer, File "/home/vfperri/.local/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in write _check(retval) File "/home/vfperri/.local/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check raise USBError(_strerror(ret), ret, _libusb_errno[ret]) usb.core.USBError: [Errno 5] Input/Output Error

I'm googling the errors and still nothing :(

Thanks a lot.

Víctor

florentbr commented 2 years ago

I've never encountered this error. Mabe be a port configuration or access rights. Is it working with the application on both Windows and Linux ? Can you post the USB descriptor from linux lsusb -vvv -d 5345:1234 ?

vfperri88 commented 2 years ago

With the application in working perfecly in both Windows and Linux. Here is the output of lsusb:

Bus 001 Device 004: ID 5345:1234 Owon PDS6062T Oscilloscope Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x5345 Owon idProduct 0x1234 PDS6062T Oscilloscope bcdDevice 1.00 iManufacturer 1 ZHBI2.0 iProduct 2 ZPRO2.0 iSerial 3 VDS1022 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0029 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 5 Physical Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 09 21 11 01 00 01 22 5f 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)

Yesterday I was also having troubles with a Mac, today I'm going to try this update also in that Mac to see if know it is working.

florentbr commented 2 years ago

The OUT endpoint is 0x01 in your descriptor while it is 0x03 with my device. Looks like you've got a new board version. It should work with your device by changing USB_EP_WRITE in vds1022.py.

--- a/api/python/vds1022/vds1022.py
+++ b/api/python/vds1022/vds1022.py
@@ -122,7 +122,7 @@ HTP_ERR = 10  # Horizontal trigger position correction
 USB_VENDOR_ID = 0x5345
 USB_PRODUCT_ID = 0x1234
 USB_INTERFACE = 0
-USB_EP_WRITE = 0x3
+USB_EP_WRITE = 0x1
 USB_EP_READ = 0x81
 USB_TIMEOUT = 200
vfperri88 commented 2 years ago

¡¡You are right!! now I have another problem but I think thats also a problem because some diference in my version of board.

Traceback (most recent call last): File "/home/vfperri/Documentos/Electrónica/Osciloscopio/Ejemplos/testOsciloscopiov01.py", line 3, in dev = VDS1022() File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1100, in init self._load_flash() File "/home/vfperri/.local/lib/python3.10/site-packages/vds1022/vds1022.py", line 1388, in _load_flash assert flash_header == 0x55AA, "Bad flash header %d" % flash_header AssertionError: Bad flash header 43605

I'll let you know when I can solve the problem!

Thanks a lot!

Víctor

florentbr commented 2 years ago

The value 43605 is 0xAA55 in hexa. Can you try:

- assert flash_header == 0x55AA, "Bad flash header %d" % flash_header
+ assert flash_header == 0xAA55, "Bad flash header %d" % flash_header
vfperri88 commented 2 years ago

Now I have some issue with the GET_FPGALOADED, I think the address of the command are not the same in this new version. I try to get the new ones debbuging the application but I can't see the new addresses. Do you do get the old addresses sniffing the USB?

env: Windows 10, Java 1.8.0_331 amd64 app dir: C:\Program Files\OWON VDS1022 user dir: C:\Users\vfperri\AppData\Local\OWON VDS1022 locale: en, es_AR, false [Send @MACHINE_TYPE_ADD 0x56] recv V 0x1 found usb device VDS1022 idVendor:0x5345 idProduct:0x1234 [Send @FPGA_DOWNLOAD_QUERY_ADD 0x0] recv 0x1 fpga loaded: 1 read flash [Send @read_flash 0x1] recv 2002 bytes flash size: 2002 flash crc32: 2338603330 flash header: 0x55 0xAA flash oem: true flash board version: V4.0.0 flash board serial: VDS1022I2142530 load calibration C:\Users\vfperri\AppData\Local\OWON VDS1022\VDS1022I2142530-cals.json Gain CH0 : [1263, 1112, 982, 814, 685, 554, 989, 859, 731, 560] Gain CH1 : [1275, 1114, 984, 813, 685, 556, 989, 860, 732, 560] Step CH0 : [365, 364, 364, 364, 363, 364, 363, 363, 363, 363] Step CH1 : [364, 363, 364, 363, 364, 363, 364, 363, 362, 363] Compensation CH0 : [1396, 1402, 1405, 1406, 1403, 1400, 1404, 1405, 1403, 1400] Compensation CH1 : [1374, 1391, 1394, 1393, 1392, 1390, 1394, 1392, 1391, 1391] [Send @TRG_ADD 0x0] recv S 0x0 [Send @trg_holdoff_ext_ADD 0xffff8002] recv S 0x0 [Send @pulse_level_ch1_ADD 0xf19] recv S 0x0 [Send @channel_ch1_ADD 0xffffffa0] recv S 0x0 [Send @volt_gain_ch1_ADD 0x22a] recv S 0x0 [Send @zero_off_ch1_ADD 0x578] recv S 0x0 [Send @CHL_ON_ADD 0x1] recv S 0x0 [Send @channel_ch2_ADD 0x20] recv S 0x0 [Send @volt_gain_ch2_ADD 0x22c] recv S 0x0 [Send @zero_off_ch2_ADD 0x56e] recv S 0x0 [Send @DM_ADD 0x13ec] recv S 0x0 [Send @SYNCOUTPUT_ADD 0x0] recv S 0x0 [Send @TIMEBASE_ADD 0x190] recv S 0x0 [Send @SAMPLE_ADD 0x0] recv S 0x0 [Send @SLOWMOVE_ADD 0x0] recv S 0x0 [Send @PRE_TRG_ADD 0x9f6] recv S 0x0 [Send @SUF_TRG_ADD 0x9f6] recv S 0x0 [Send @EMPTY_ADD 0x1] recv S 0x4e554c4c [Send @TRG_ADD 0x0] recv S 0x4 [Send @trg_holdoff_ext_ADD 0xffff8002] recv S 0x0 [Send @pulse_level_ch1_ADD 0xf19] recv S 0x0 [Send @channel_ch1_ADD 0xffffffa0] recv S 0x0 [Send @volt_gain_ch1_ADD 0x22a] recv S 0x0 [Send @zero_off_ch1_ADD 0x578] recv S 0x0 [Send @CHL_ON_ADD 0x1] recv S 0x0 [Send @channel_ch2_ADD 0x20] recv S 0x0 [Send @volt_gain_ch2_ADD 0x22c] recv S 0x0 [Send @zero_off_ch2_ADD 0x56e] recv S 0x0 [Send @DM_ADD 0x13ec] recv S 0x0 [Send @SYNCOUTPUT_ADD 0x0] recv S 0x0 [Send @TIMEBASE_ADD 0x190] recv S 0x0 [Send @SAMPLE_ADD 0x0] recv S 0x0 [Send @SLOWMOVE_ADD 0x0] recv S 0x0 [Send @PRE_TRG_ADD 0x9f6] recv S 0x0 [Send @SUF_TRG_ADD 0x9f6] recv S 0x0 [Send @EMPTY_ADD 0x1] recv S 0x4e554c4c windowClosing releaseConnect

Thanks a lot,

Víctor

florentbr commented 2 years ago

The commands that changed with the new board are the trigger Pulse/Slope width. These new commands are already present in vds1022.py and are selected according to the board version obtained by reading the flash of the device. All the other commands are the same. I'm pretty sure since I inspected each change made by OWON in their official release.

Fyi the command FPGA_DOWNLOAD_QUERY_ADD is GET_FPGALOADED in vds1022.py. If the returned value is 1, the firmware is already loaded/present. The firmware needs to be sent again if the device is disconnected.

It could be that it's not loading the correct FPGA firmware.

Post the logs from python. It should be easy to identify the issue:

from vds1022 import *

dev = VDS1022(debug=True)
dev.set_timerange('5ms')
dev.set_channel(CH1, range='10v', coupling=DC, offset=0, probe='x1')
frames = dev.pull()
print(frames.ch1.rms())
vfperri88 commented 2 years ago

Hi, I could solve it, the problem was the status that the script was waiting of GET_FPGALOADED, I changed it from GET_FPGALOADED = Cmd('GET_FPGALOADED' , 0x0223, 1, E) to GET_FPGALOADED = Cmd('GET_FPGALOADED' , 0x0223, 1, 0)

And now is working just perfect! thanks a lot! :)

Just in case, here is the log that you ask me for:

[ GET_MACHINE 0x56 ] 0x1 [ READ_FLASH 0x1 ] 0x7d2 oem=1 version=V4.0.0 serial=VDS1022I2142530 phasefine=0 crc32=8B644142

Victor

nhorlock commented 2 years ago

My VDS1022I bought in the last month or so, matches the newer board that @vfperri88 has, and similar changes have allowed me to get mine to respond.

In an attempt to make things less hardcoded (in terms of the endpoint addresses for example) I've added 

        self._ep_write = usb.util.find_descriptor(
                            self._intf,
                            # match the first OUT endpoint
                            custom_match = \
                            lambda e: \
                            usb.util.endpoint_direction(e.bEndpointAddress) == \
                            usb.util.ENDPOINT_OUT).bEndpointAddress
        self._ep_read = usb.util.find_descriptor(
                            self._intf,
                            # match the first OUT endpoint
                            custom_match = \
                            lambda e: \
                            usb.util.endpoint_direction(e.bEndpointAddress) == \
                            usb.util.ENDPOINT_IN).bEndpointAddress

It is mostly overkill but no real hardship and should futureproof against such changes. The 0x55AA versus 0xAA55 change in the header seems pretty weird and I'm not sure how handle that unless we just have in load_flash assert flash_header == 0xAA55 or 0x55AA, "Bad flash header %d" % flash_header" but that doesn't fix the write and sync flash methods

florentbr commented 2 years ago

@nhorlock, I've already fixed the endpoint and header but I still have to find a solution for the status of the command. I think I will just ignore this status just like the official application.

For the endpoints, I'm now using the ones available:

            if desc.idVendor == USB_VENDOR_ID and desc.idProduct == USB_PRODUCT_ID:
                handle = usb.open_device(dev)
                self._handle = handle

                for ep in dev.config[0].interface[USB_INTERFACE].altsetting[0].endpoint[:2]:
                    if ep.bEndpointAddress & 0x80:
                        self._ep_read = ep.bEndpointAddress  # 0x81
                    else:
                        self._ep_write = ep.bEndpointAddress  # 0x3 or 0x1

                assert self._ep_read is not None and self._ep_write is not None

For the flash header, I'm checking both:

        assert flash_header in (0x55AA, 0xAA55), "Bad flash header: 0x%X" % flash_header

Are the write and sync flash methods also failing with your device ? It should work as is if they just forgot to invert the header before programming the chip. If it's not working with [0x55, 0xAA], I'll just store and invert the header.

nhorlock commented 2 years ago

ahh excellent. We were both doing the same changes :-) As for the flashing, it'll work I expect, I was not sure how important it was if we were reflashing with the byte-swapped version. I'll pull the latest updates and have a look

florentbr commented 1 year ago

fixed in release 1.1.3-cf17

kishore-R10 commented 3 months ago

does vds3104 have sdk?