Flashing Firmware error is back?

[damercer]

I'm getting strange errors when trying to flash new frmware on the M1K. I'm using a test version of Libsmu that was a temp fix to the split I/O switch issue ( i.e. not current Master). This is the filename string I sent to the function: C:/Users/Doug/Documents/RPI/ADiscovery/ALM/m1000.bin

Exception in Tkinter callback Traceback (most recent call last): File "C:\Python27\lib\lib-tk\Tkinter.py", line 1537, in call return self.func(*args) File "C:\Users\Doug\Documents\RPI\ADiscovery\ALM\rework\alice-desktop-1.2.pyw", line 14779, in UpdateFirmware session.flash_firmware(filename) File "pysmu\libsmu.pyx", line 337, in pysmu.libsmu.Session.flash_firmware SessionError: failed opening USB device: Operation not supported or unimplemented on this platform

The board gets put in programing mode but the new firmware is never up loaded. I thought this was working. I think there was some issue with USB divers that I fixed on this computer. Could someone refresh my memory as to what I need to change to get this working again?

Thanks

Doug

[damercer]

I tried to remove and re-install the drivers from the 64 bit Libsmu installation (libsmu-1.0.1-g6dda3cf-setup-x64) but I'm still getting only this driver:

ADALM1000 WinUSB driver

not the proper one:

ADALM1000 SAM-BA WinUSB driver

Which version of libsmu installer has the proper drivers?

Doug

[damercer]

I was able to set the proper drivers from the Sept 10 version of Pikelpulse2 installer.

Pixelpulse2 does not run properly on my computer however because my Video card is older and does not support the modes used by Qt.

I know you all have been trying to build the libsmu and pixelpulse installers with the right drivers but they don't always seem to have it right yet.

Thanks

Doug

[damercer]

I had libsmu uninstalled when I loaded Pixelpulse2 above. When I went to reinstall libsmu (x86) with the install drivers box NOT checked it changed back to ADALM1000 WinUSB driver and now I can't get back to ADALM1000 SAM-BA WinUSB driver by uninstalling the driver and forcing it to look in the either the driver or drivers directories under the pixelpulse2 installation folder.

Help!

Doug

[AlexandraTrifan]

Hi

The temp fix for I/O switch did not have the right drivers, that may be the reason the flash firmware did not work. Pixelpulse, the version from 10 September has the right drivers, as you said. The libsmu installer should be used from the branch test-driver for now (I did not want to create an official release until the issues regarding this are fixed). I think you can uninstall Pixelpulse and any libsmu version from your computer and in the Device Manager, right click on the ADALM1000 WinUSB driver, try to Uninstall it and check the box that completely deletes the driver. I think that some old/wrong driver got installed at some point. The Pixelpulse installer should be able to replace the bad driver, but you can clean it up, just to be sure.

After that, you can use the libsmu installer from here (https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/1.0.1149/job/gyqut93wbk2sy4l1/artifacts). It is not signed, because it's a nightly build. Also, the failing status of the build has nothing to do with the installer, just some python MINGW dependencies that I am working on fixing. I just tested using this installer. The drivers were correctly installed and the firmware flashing worked using pysmu. Please let me know if that's the case for you too.

Thank you.

-Alexandra

[damercer]

Hi: Thanks for pointing me to the "correct" libsmu installer but does this new one 1.0.1149 have both the switch fix ( can't proceed without it ) and the proper USB drivers?

Doug

[AlexandraTrifan]

It doesn't have both. Let me just merge the changes, test the switch addition and get back to you.

-Alexandra

[damercer]

One other quick clarification. I use 32 bit Python so I must install the X86 version. But my computer is 64 bits so it need 64 bit divers. Will the X86 installer have both drivers?

Thanks

Doug

[AlexandraTrifan]

Hi

If you want to use the quick fix that you used before, you can try this version (https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/1.0.1153). But, as i said in the issue regarding the feedback control switch, this isn't the final version for the switch control.

I've implemented the switch control using 3 new modes (HI_Z_SPLIT, SVMI_SPLI,T...) on this version (https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/1.0.1152 ). This one should set the switch on/off corresponding to the mode you chose. If you try this one, please let me know whether it works fine, since this is still WIP and not 100% tested.

Both the installers contain x86 and amd64 required dlls, and the m1k-winusb driver should choose the right one for your machine.

Thank you

-Alexandra

[damercer]

I uninstalled libsmu and the existing drivers from the control panel. I then ran the X86 version of 1.0.1152 ( because I made a test version to try new modes ) and it stopped with a message saying that I need ed to install the 64 bit drivers for this machine so what you just said is not true.

Like before it looks like I have to first install using the 64 bit installer with just the drivers checked and then try the X86 version with just libsmu and python checked.

Thanks

Doug

[damercer]

Sorry, it is still coming up with just the wrong ADALM1000 WinUSB driver not the proper ADALM1000 SAM-BA WinUSB driver.

What extra do I need to do to remove these wrong drivers from this computer???

Thanks

Doug

[damercer]

I uninstalled the existing ADALM1000 WinUSB driver with the delete software box checked. I then manually installed the driver from the libsmu 64 bit drivers folder. It STILL came up with the wrong ADALM1000 WinUSB driver not the proper ADALM1000 SAM-BA WinUSB driver.

[damercer]

This is very strange behavior?? If I do a hard reset i.e. short the jumper on the M1K to put it in program mode the driver shown in the device manager changes to ADALM1000 SAM-BA WinUSB driver. If I then use ALICE (Python) to flash new firmware it flashes properly and when I cycle the board power the driver shown in the device manager changes to the old ADALM1000 WinUSB driver??? Now if I try to flash the firmware the board is set into program mode and the program crashes, but cycling the power (now that board is in program mode ) changes back to ADALM1000 SAM-BA WinUSB driver. AND the circle is complete.

What the heck is going on here!

Doug

[damercer]

I have a guess at something that might make flashing through libsmu/pysmu work every time would be to insert a wait time between placing the board into programming modes and attempting to write the firmware. Or testing to see if the USB connection was reestablished. Windows needs more time to switch to new driver for when board is in programming mode. Just something I noticed when trying this multiple times. Doug

[AlexandraTrifan]

The ADALM1000 SAM-BA WinUSB shows up when the board is in programming mode, while the ADALM1000 WinUSB shows up when the board is not in programming mode. It should not be wrong. The flash_firmware feature should always leave it using the ADALM1000 WinUSB name. I tested using the latest firmware file and an old one. The following snippet is what i tested and it worked on multiple attempts. `

s = Session() s.flash_firmware(m1000old.bin)

device shows up as ADALM1000 WinUSB SAM-BA

unplug and replug -> device shows up as ADALM1000 WinUSB

s.add_all() s.flash_firmware(m1000.bin)

device shows up as ADALM1000 WinUSB SAM-BA

unplug and replug -> device shows up as ADALM1000 WinUSB`

I've seen an error when flashing the firmware if I don't run the s.add_all(), then the Session complains about not having any device in SAM-BA mode. But after running s.add_all(), a new scan is performed and the device is detected, so I managed to run the second flash_firmware. Could you please provide the script or commands you used to run these tests?

-Alexandra

[damercer]

I understand the driver name difference now but it is somewhat confusing.

However, the crashing still remains. This is not a Python crash but a C++ crash: I'm trying to flash the 2.15 version of the firmware to a board (rev D) with 2.15 loaded.

Doug

[damercer]

The crash does not seem to happen on another Win 7 lap top computer but always crashes on this Dell desk top computer (both 64 bit Win 7). Seems to be a timing (OS response to board changing to program mode) issue. As I said there needs to be a (variable?) delay between the operations in Libsmu. Would it be possible to have a debugging version where the two functions, putting board in program mode and uploading firmware, are in separate Python functions so I can insert delay/tests in between?

Doug

[AlexandraTrifan]

I created a test version with the two steps split. First you need to run s.put_in_samba_before_flash() and after that you can run s.flash_firmware("path") as you did before. I removed the programming mode related things from the flash_firmware method. https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/1.0.1156

[damercer]

Interesting.... It now crashes (same error screen) when attempting the session.put_in_samba_before_flash() it never gets to the print statement.

session.put_in_samba_before_flash()
print "Waiting 5..."
time.sleep(5)
print "Now Fashing..."
session.flash_firmware(filename)

Not sure what to try next? Doug

[damercer]

Good news, sort of anyway. I noticed in Pixelpulse2 you have the following line before flashing the firmware: session.closeAllDevices();

I added what I think might be similar for Python: session.cancel() ( maybe you know which pysmu function is closest to session.closeAllDevices(); )

And not the C++ level does not crash. The session.flash_firmware(filename) still returns a Python level error/warning message but does not stop Python. Not sure why this is needed on this computer and not others but seems to work without hurting anything.

Thanks

Doug

[AlexandraTrifan]

closeAllDevices() in PixelPulse calls session.cancel(), then session.end() to block until all devices have completed and then session.remove(device) on each device, to remove it from the current session. These 3 actions are all available in pysmu. Can you try using this approach and check if Python still returns some errors?

Thank you -Alexandra

[cristi-iacob]

Tested them on the new version of libsmu, and they seem to work properly now. Thanks!