Python support?

[siguy]

Hi serg, as shown in my previous post - i get empty strings, so sub_get_serial_number() returns 0, as does sub_get_product_id()

In debugging the SUB-20-120121_x32 package install, oddly, the sub20.dll goes into system32 - i thought the 64bit drivers go there and the 32bit ones go to SysWOW64 on Win7-x64?

I'm able to get my Python code working again simply by reverting to FW 0.3.3 - it is broken with 0.3.5 as previously mentioned. DLL is 1.26.0.0 in System32 when SUB-20-120121_x32 was installed.
I don't think my Python code is the issue, but I suspect maybe DLL and FW version incompatibility due to mildy differing data structures and interfaces or 32bit vs 64bit issues.

As for the runtime being long - I found the root cause - it is the USB slot in my system. Going to a different slot solves the issue. Perhaps Windows has a couple drivers trying to access the same port the SUB-20 is on and times out or something. I will continue to monitor fresh systems where this is installed to see if it shows up again.

Thanks,
SIguy

[serg]

Hi Slguy,

Something is definitely wrong with the installation. I just tried installing SUB-20-120121-x32.exe on a fresh Win7-x64 system. The sub-20.dll goes to the proper folder i.e C:\Windows\SysWOW64. Normally, Windows won't load 32-bit dll from the system32 directory on 64-bit OS. So, I don't understand how subtool is able to find and load sub20.dll. I suspect you have more than one copy of this dll somewhere. I even tried to move the dll manually to the system32 folder. In this case when I try to launch the subtool.exe I get the system error "Cannot find sub20.dll". So, first let's find out why this happen.
Then, we have to find out why one app(subtool) is working properly with the sub20.dll and another app(Python interpreter) doesn't work properly with the same dll. I still don't understand how firmware update makes the difference, i.e how firmware "knows" which app on a PC is calling it? The only explanation I have is that apps pass different parameters to the sub_get_serial_number. Or may be a timing issue? Is this a virtual machine or real one?
So, let's get back to the installation first. Before moving forward I would try to find out why this happen. Try to rename the saub20.dll. Does the subtool still works? Could you please try to execute the following on a command line prompt. This is yet another app(command line tool) which uses the sub20.dll

C:\Program Files\SUB-20\bin>sub_app --getsn

Let me know.

[siguy]

Hi serg,

Tried the install on a fresh machine and it does put it correctly into SysWOW64. Using SUB-20-120121-x32, the sub_app you listed returns the correct SN with both FW 0.3.3 and 0.3.5. However, with FW 0.3.5, my Python calls are still seeing the same bulk write fail, but SUBTOOL works.

If you can get the earlier Python example working with FW 0.3.5 and the 32-bit DLL 1.26.0.0, I'd be happy to make the changes you find! As of now, that code will only return empty strings for get_product_id and get_serial_no. Simply changing to FW 0.3.3 allows it all to work.

Thanks,
SIguy

[serg]

Just tried the attached script which is slightly modified mdio script from here viewtopic.php?f=2&t=334
It works properly on my Virtual Win7x64. The Python package is python-3.2.3.msi. The SUB-20 package is SUB-20-120121-x32.exe
Below is the output of the script.

Code: Select all

C:\Program Files\SUB-20\bin>C:\Users\user0\Desktop\mdio.py
device id is: 38275704 sub_errno is: 0
Product ID: SUB-20
Serial Number: 0000
device id is: 38275704 sub_errno is: 0
returned is: 0 sub_errno is: 0

C:\Program Files\SUB-20\bin>sub_app.exe --version
XDimax LTD, V0.2.3, Jan 21 2012 16:59:49
DLL/Lib: 0.0.2.27
Driver : 0.0.2.0
SUB-20 : 0.3.5
Boot   : 0.5

C:\Program Files\SUB-20\bin>ver

Microsoft Windows [Version 6.1.7600]

C:\Program Files\SUB-20\bin>

Could you please try to launch it on your system and send me the output. Also, could you please send me the debug trace. You can find how to capture the trace here viewtopic.php?f=2&t=499&p=1218&hilit=trace+log#p1218
Thanks

[siguy]

Hi serg,

Thanks for your efforts - I did try paring it down to a simpler case but not all the way back to the original...my bad! Using your original script and slowly converging to mine, I found the issue.

My code has the sub_open in a function and dev_id is global. At the start of my version of get_device_info, I do a sub_reset to make sure the sub_handle/dev_id passed in, is valid.

I've attached the pathological test case - all that was added was a sub_reset call in get_device_info. After sub_open but before get_product_id.

To reproduce my issue, run the script with FW 0.3.3 and FW 0.3.5 - in the latter case, it will return empty strings after sub_reset. With 0.3.3 - it will return correct IDs. The offending call is sub_reset() - remove it and the behavior of 0.3.3 and 0.3.5 are identical.

I'm unblocked at this point and have finished my development, but I'm still curious on the root cause, so do let me know what you find!

Thanks,
SIguy

[serg]

Hi Slguy,

Great!

From your script:
# sub_reset appears to be handled differently in 0.3.3 vs 0.3.5

Now it makes more sense to me. The sub_reset is not available in firmware 0.3.3. This is a new feature added in the 0.3.5. See the "Firmware releases" for details viewtopic.php?f=2&t=3
As part of the SUB-20 CPU reset the SUB-20 USB device is reconnected, so the handle becomes invalid. In order to fix the issueyou should close the handle and open it again after the sub_reset call. BTW, what do you want to achieve by "reset"? Normaly, this is not necessary to reset the SUB-20 board.

[siguy]

Thanks serg for the information - it all makes sense now. I was only planning to use sub_reset to see if the handle was valid when I do not have an MDIO target to test with - any of the get_* commands have the same effect on testing a valid handle, so I should never need to use sub_reset. It might be a good idea to add to documentation that the sub_reset will cause a new handle to be generated - it isn't clear from current docs and may save another user a little debug time.

[serg]

Sure, we will update the manual regarding the sub_reset functionality. Thanks