search

analogdevicesinc / libsmu

Software abstractions for the analog signal exploration tools.
http://analogdevicesinc.github.io/libsmu/
BSD 3-Clause "New" or "Revised" License
32 stars 31 forks source link

Is session.flash_firmware(filename) fully implemented in pysmu? #112

Closed damercer closed 5 years ago

damercer commented 6 years ago

Has the ability to flash new firmware to M1K been fully implemented in pysmu? I see there is flash_firmware method defined in both cdef class Session: and cdef class SessionDevice(Device): Is there any difference between the two and how are they used?

I use the following code to test:

def UpdateFirmware():
    global devx, dev0, dev1, dev2, session, BrdSel, CHA, CHB, DevID, MaxSamples
    global bcon, FWRevOne, HWRevOne, FWRevTwo, HWRevTwo, WRevThree, HWRevThree

    if askyesno("Update current firmware","Flash new firmware to current device (Yes) or (No):\n"):
        filename = askopenfilename(defaultextension = ".bin", filetypes=[("Binary", "*.bin")])
        print filename
        print DevID
        print devx.fwver, devx.hwver
        session.flash_firmware(filename)

It returns the following ( running a Rev E board with FW version 2.13 trying to load v2.09):

C:/Users/Doug/Documents/RPI/ADiscovery/ALM/m1000-209.bin 2031305436363037323530323130303 2.13 E 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 13552, 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 now has the firmware wiped and is back in bootloader. I then can use BOSSA to reload firmware. So it seems it is partially implemented or am I doing something wrong?

Thanks

Doug

claudiupop commented 6 years ago

Both of the methods should work. The one that is implemented in Session is to flash firmware on one or multiple devices at once (including the ones that are in programming mode). The otherone that is implemented in SessionDevice is to flash firmware to the device that it is called on.

Until rework, to flash the firmware for the devices there was a dependency for the BOSSA. With rework the BOSSA is not needed anymore.

That error is caused by not having the correct driver, for m1k, installed. Windows, for some reason, it doesn't install the driver that comes with libsmu but the one that work with BOSSA. When libsmu is looking for devices in programming mode, it is looking after ADALM1000 WinUSB devices and doesn't find any.

The way I found to install the correct driver is to put the device in programming mode. Make sure you have Disconnect the network ( so that windows doesn't automatically installs the wrong driver) . Then follow this steps:

It is not the easiest thing, but I could't find any other method to get the right drivers installed.

Thanks

damercer commented 6 years ago

I will try this method to load the proper driver when I get a chance.

The libsmu installer has an option to install the usb driver. Does that not install the correct driver? Should I have left that option selected when I installed the latest libsmu? The Pixelpulse2 installer might also install usb driver, don't know I never use Pixelpulse2, does that install the proper driver?.

I think we need a simple way for existing uses who installed their M1K software some time ago ( original master libsmu ) to upgrade to the proper driver.

Thanks

Doug

On 1/17/2018 7:14 AM, claudiupop wrote:

Both of the methods should work. The one that is implemented in Session is to flash firmware on one or multiple devices at once (including the ones that are in programming mode). The otherone that is implemented in SessionDevice is to flash firmware to the device that it is called on.

Until rework, to flash the firmware for the devices there was a dependency for the BOSSA. With rework the BOSSA is not needed anymore.

That error is caused by not having the correct driver, for m1k, installed. Windows, for some reason, it doesn't install the driver that comes with libsmu but the one that work with BOSSA. When libsmu is looking for devices in programming mode, it is looking after ADALM1000 WinUSB devices and doesn't find any.

The way I found to install the correct driver is to put the device in programming mode. Make sure you have Disconnect the network ( so that windows doesn't automatically installs the wrong driver) . Then follow this steps:

  • Right click on my computer -> Manage
  • In the window that was opened, choose from the left column Device Manager
  • In the Universal serial bus devices something with BOSSA in name (I can't remember the right name, and I can't make the computer to install the wrong driver)
  • After you identify the driver, right click -> uninstall and a pop-up windows should appear.
  • Check the box "Delete the driver software for this device"
  • Now the device should not be in the list anymore
  • Right click on any item from the list -> Scan for hardware changes
  • The Windows now should see the device but cannot find any driver for it and it will see it as Unknown device in the Other devices category.
  • Right click on the unknown device and click Update Driver Software and then Browse my computer for driver software.
  • Browse to the location of driver where you have libsmu installed (or you can download from releases or appveyor an archive with libsmu and the drivers, if you choose this method browse to the folder where you extracted it),make sure the checkbox with Include subfolders and press OK.
  • After that click Next and a pop-up may appear and click install.
  • The driver should succesfully intall and you should see in the Universal Serial Bus devices -> ADALM1000 SAM-BA WinUSB driver
  • Now the flash firmware method should work.

It is not the easiest thing, but I could't find any other method to get the right drivers installed.

Thanks

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/analogdevicesinc/libsmu/issues/112#issuecomment-358286768, or mute the thread https://github.com/notifications/unsubscribe-auth/ALIL6qBXvv80C9ApjaHGHuT_VU8ngLKRks5tLeQlgaJpZM4RgAAx.

claudiupop commented 6 years ago

I managed to install the wrong driver again. If you have x64 bit version of windows (i do) if i use the x86 libsmu installer, it doesn't install the correct drivers, but when I used the x64 bit libsmu installer and checked the option to install the usb driver, it installed the correct driver. On x86 version of Windows using the x86 installer should theoretically install the correct drivers.

So on x64 Windows version you need to use x64 libsmu installer to successfully install the correct drivers.

damercer commented 6 years ago

I'm still having a problem with getting the correct usb driver installed apparently. This is what I tried. Because I only have 32 bit Python installed.... I uninstalled libsmu X86 and installed libsmu libsmu-1.0.1-g6dda3cf-setup-x64.exe with the install usb driver checked. The install usb driver wizard poped up for a short time ( I assumed it installed a new driver). With 64 bit libsmu my 32 bit Python program will not run with that pysmu. So I reinstalled X86 libsmu but with the install usb drive option not checked. Ran my program and I think it did the same thing where it wiped the frimware but could not find the board on the serial port and returned the error.

In the device manager the reset board appears as Bossa Program Port (COM4). I can reload the firmware using bossa.

A board with running firmware appears as ADALM1000 WinUSB driver in the device manager. So I think it still is using the wrong driver and the 64 bit version of libsmu installer didn't actually change the driver?

I will investigate further and get back to you if I find any new info.

Thanks

Doug

damercer commented 6 years ago

I was able to manually uninstall the WinUSB driver and manually install the correct USB driver from the libsmu drivers directory. I'm not sure I followed the above steps exactly but the result was the same. Now the session.flash_firmware(filename) works but I needed to cycle the power for my program to reconnect to the board.

Before I release this in ALICE to the general public I think we need a better way of: 1: determining if the proper USB driver is installed before the libsmu function wipes the firmware. 2: Removing and installing the proper driver.

Thanks

Doug

damercer commented 6 years ago

You might need to look into adding a delay, or a check to see if the operation completed, between when the board is reset into the bootloader and when the new firmware write operation is started. Some computers running at different speeds may take more time for the OS to recognize the switch in the board. My Python program hangs ( never returns from session.flash_firmware(filename ) on a board that is running firmware vs a board already in the bootloader.

Thanks

Doug

claudiupop commented 6 years ago

On my laptop when i use the x64 libsmu installer it installs the correct driver. If the correct driver is installed the board in programming mode should be seen as 'ADALM1000 SAM-BA WinUSB' and not as 'Bossa Program Port'.

I think that the only way to check what driver is installed is to have the board in programming mode and check in Device Manager if the board is seen as 'ADALM1000 SAM-BA WinUSB' (the correct one) or as 'Bossa Program Port' (the bad one). This is because the board in programming mode is seen by Windows as a different device so only then you can check the driver.

I don't know if there is another way to check if the correct driver is installed before the board is in programming mode. For installing the correct driver I think the way you did it is the easiest. Uninstall the bad driver and install the correct one from the libsmu driver folder.

Can you give me some more details about,what that delay / check would do ?

Flash_firmware method should not hang in any case. Can you put here the program that hangs ?

Thanks

damercer commented 6 years ago

A couple of things. First, I have a computer with Windows OS 8 32 bit installed. The one I use for demos at conferences lie ECEDHA. Can you make a version of the X86 installer that contains the proper USB drivers? I can temporarily load the 64 bit libsmu (X64) to get the proper drives like I did with the desktop Win 7 computer.

Second, I tried loading new firmware onto this board I've been testing with a few times this morning and it always seemed to complete properly. But Yesterday it didn't every time. Must have been related to some other background task that happened to be running at that time. Do you have a way to check the timing for the board to return as 'ADALM1000 SAM-BA WinUSB' ?

If you can get me a copy of the proper driver to load on the slower Win 8 32 bit OS then I can test over on that computer as well. Or can I just copy the divers from libsmu X64 or will that not work?

Thanks

Doug

claudiupop commented 6 years ago

The only problem with x86 libsmu installer is that the program that is used to install the drivers (which also is x86) cannot be used to install the x64 driver, and that's why you have to use the x64 installer on 64 bit Windows to get the right drivers.

On x86 Windows, the x86 installer can install the correct drivers.

damercer commented 6 years ago

Ok but I'm not sure I follow you on how to get the correct drivers loaded on my 32 bit Windows 8 computer. I can't install X64 to get drivers. X86 does not seem to contain drivers.

So again how do I obtain driver files to load on 32 bit Windows 8.

Thanks

Doug

On 1/19/2018 6:43 AM, claudiupop wrote:

The only problem with x86 libsmu installer is that the program that is used to install the drivers (which also is x86) cannot be used to install the x64 driver, and that's why you have to use the x64 installer on 64 bit Windows to get the right drivers.

On x86 Windows, the x86 installer can install the correct drivers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/analogdevicesinc/libsmu/issues/112#issuecomment-358943433, or mute the thread https://github.com/notifications/unsubscribe-auth/ALIL6sRipWV6UAIjY3irXo24QZZJcfq9ks5tMH_zgaJpZM4RgAAx.

claudiupop commented 6 years ago

Use the x86 libsmu installer to install libsmu and the drivers on your 32 bit Windows 8 computer. If you tried this and it didn't installed the drivers, there may be a problem.

Thanks.

damercer commented 6 years ago

Like I said the X85 installer on a 32 bit Windows computer DOES NOT include option to install USB drivers.

x86-installer

So again I ask. How do I obtain the right drivers for 32 Windows 8?

Thanks

Doug

claudiupop commented 6 years ago

I understand now, that is a problem.

An alternative to this is to download libsmu-1.0.1.zip (https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/job/u57xft7kvu3wmd8c/artifacts) and extract it. Go to device manager and find the device ( Bossa Program Port) -> right click and Update driver software -> select Browse my computer for driver software -> Browse to the location where you extracted the libsmu archive and select the drivers folder. Click Next and is should install the correct driver, and overwrite the bad one.

damercer commented 6 years ago

That was successful. It took some bashing to get Windows to delete the old driver but once it did loading driver from zip file resulted in the board without firmware coming up in the device manager as 'ADALM1000 SAM-BA WinUSB' .

If you have a solution for fixing the X86 version of the installer .exe then I can close out this issue.

Doug

claudiupop commented 6 years ago

This version ( https://ci.appveyor.com/project/analogdevicesinc/libsmu/build/1.0.1123/job/qbcll6996bs3s8a7/artifacts ) should show the option to install USB drivers.

damercer commented 6 years ago

I down loaded that version of the X86 installer to my 32 bit OS and Windows will not let me run it. The previous version will run ( obviously because that is the one I'm currently using ). Says it is not a recognized program ( vendor?) and Windows Protection refuses to run the program. May be you set some protection settings wrong?

Thanks

Doug

claudiupop commented 6 years ago

The only thing I changed is to always show the option to install the driver, before, that option would only show on windows 7 and older versions of windows. Now your windows 8 , is seeing that the installer wants to install a driver and the executable is not signed and it blocks it. This shouldn't be a problem with a signed installer.

I think that you can install this version, by clicking on "more info" , and then a button with "Run anyway" should appear.

If this doesn't help, could you post a printscreen with the message?

Thanks

damercer commented 6 years ago

In Windows 8 there is no such option. When you try to run the installer, the desktop goes away and you get a blue screen with the warning and one option, return without running. Sorry I don't think there is a way to get a screen capture while it is showing the message. ADI needs to have a way to publish "signed" programs.

Doug

claudiupop commented 6 years ago

Don't you get something like this ? https://media.askvg.com/articles/images4/Windows_8_SmartScreen_Warning.png

damercer commented 6 years ago

Right, I didn't notice the greyed out more info. Still does not change the fact that ADI needs to be able to publish signed programs that don't throw up that warning message. Very disconcerting to the average user.

Doug

On 1/29/2018 9:05 AM, claudiupop wrote:

Don't you get something like this ? https://media.askvg.com/articles/images4/Windows_8_SmartScreen_Warning.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/analogdevicesinc/libsmu/issues/112#issuecomment-361254885, or mute the thread https://github.com/notifications/unsubscribe-auth/ALIL6lB89yi9-oAIhqIm4ZoLHCfJMyCsks5tPdAngaJpZM4RgAAx.

claudiupop commented 6 years ago

The installers that are on appveyor are not official releases and also can't be physically signed. The installers that are published on the release page on github are all signed.

cristi-iacob commented 5 years ago

I've tested the installer from the next libsmu version and it works properly. Thanks!