CWCapture from gitub has errors while starting

[rogerclarkmelbourne]

Steps to repeat.

Install Linux Mint x64 Follow installation instructions on Wiki for Linux (Ubuntu)

Git was cloned today 2018/05/14 and seems to be using development branch from this commit

https://github.com/newaetech/chipwhisperer/commit/9fdf3a6bca01296c8a86189d82dacb1f05f4ccb2

Observe error / warnings message while starting CWCapture from command line

python CWCapture.pyw
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
INFO:Could not import module: chipwhisperer.capture.auxiliary.FrequencyMeasure: No module named matplotlib.mlab
INFO:Dictionary contains zero modules
QWidget::setWindowModified: The window title does not contain a '[*]' placeholder
INFO:Capture completed.

Looks like your installation instructions are missing the command to install matplotlib e.g.

sudo pip install matplotlib

Note. Even after matplot lib is manually installed, the following output is still displayed when starying CWCapture

python CWCapture.pyw
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
QWidget::setWindowModified: The window title does not contain a '[*]' placeholder

And example scripts don't work e.g.

execfile('/home/rclark/chipwhisperer/software/chipwhisperer/capture/scripts/setup_cwlite_xmega_aes.py')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/rclark/chipwhisperer/software/chipwhisperer/capture/scripts/setup_cwlite_xmega_aes.py", line 12, in <module>
    scope.gain.gain = 45
AttributeError: 'NoneType' object has no attribute 'gain'

However I have no idea whether this is an issue with missing modules, or whether those scripts don't work with the current version.

[colinoflynn]

The "chatty" startup messages are not errors, you need matplotlib for some additional commands but it's not needed for the SW itself to work. Thus we don't force people to install it. CW supports a huge amount of hardware/software options and there is a lot of auto-detection of potential supported devices, but it occasionally flags stuff as warnings when you don't care about them. For example there are built-in drivers for CAN, several FPGA boards, SPI, picoscope, etc.

Again the problem is I think failing to connect. Try running only a connect script and see if that works?

If you need a "known-good" setup, the VMWare is likely easiest. But I'm 99% sure the problem you are seeing is either the USB driver wasn't installed or if you are using this on bare-bones Linux it's not doing the pass-through (https://wiki.newae.com/Linux_Driver_Setup).

You should see the CW-Lite detected with 'dmesg', if that isn't working something more critical is the problem!

If it's a system you don't care about you can use 'sudo' to run cw-capture too, in case it's some permissions issue.

[rogerclarkmelbourne]

Using the VM was my next option.

As I was not getting any joy on either of my windows machines despite installing the 64 bit exe, or the 32 bit exe or manually

I think you may as well tell people to install matlib as its not a big install by modern standards and people do not like warning or error messages on startup (I get a lot of PR's on my repos if they have that sort of thing as it confuses people into thinking those messages are why their installation is not working)

I'm not sure about the QT message

QWidget::setWindowModified: The window title does not contain a '[*]' placeholder

I think you mean this can be ignored.

Anyway, I'll try installing the VM version and see if I get the same results

[colinoflynn]

If you're on Windows - a quick test first, do you see the device in the "device manager"? For some reason I've seen a bug where you DON'T get the windows driver installation wizard.

I'm still chasing that down - but you can force the driver install if you get that by selecting the CW-Lite and doing a "force update" on the driver. The ideal flow is that the thing asks for drivers, but I've seen it before where it just puts them to "warning/error" state.

The Windows "should" work fine! If you're not getting the connect to work OK it is likely something like drivers etc (or some unknown USB problem).

[colinoflynn]

PS - the drivers are a separate zip-file on the 'release' page.

[rogerclarkmelbourne]

Windows device manager is showing ChipWhisperer Lite under libusb-win32

I do have other devices installed which use libusb-win32 e.g. BlackMagic Probe

So potentially there is a driver issue

Does your diver use libusb-win32 or do I need to use something like Zadig to force Windows to use a different driver group ?

[colinoflynn]

Should be standard libusb-win32 - so far haven't run into trouble.

When you run just the connect script, do you get any error messages? It should print that it found a CW-Lite + print the S/N.

[rogerclarkmelbourne]

Looks like its connecting using the simple serial.

Scope and target are now available in the GUI

Running the multi capture at the moment but its quite slow (ETA 6 mins even on my Core i7 4GHz machine) I presume the processing speed is not dependant that much on the PC, as 6 mins of processing on a 4Ghz 64bit PC is quite a lot of processing ;-)

[rogerclarkmelbourne]

Umm After running the multi, the Trace Plot output is pretty much a flat line :-(

There is a small amount of noise being displayed, but only around 0.004 peak to peak :-(

I'll disconnect the CWL and buzz the connections between the main part of the CWL and the victim CW303

[colinoflynn]

Ah, sounds like might need to reprogram! Use the XMEGA programmer to re-program the simpleserial-aes-xmega.hex and check if it looks better...

The "setup" scripts don't program anything (to avoid blowing away), but the 'other' automation scripts do. If the file was missing it could have done erase w/o program.

[rogerclarkmelbourne]

Colin

OK.

Made some progress.

I tried the VM version but I can't get the USB to connect via VirtualBox, I'm downloading the VMWare image now, in case thats any better.

But in the mean time, I've checked out the 3.2.0 tag version in my local clone (of my fork of your repo)

I tried the AES Simple Serial XMEGA and initially I kept getting OpenADC timeouts and restarts (loads of them)

So as V3.2.0 has the CWLite XMEGA programmer on the Tools menu I reflashed

hardware\victims\firmware\simpleserial-aes\simeplserial-aes-xmega.hex

I also did a git submodule init and git submodule update as I noticed that OpenADC is a submodule and I thought that the problem could be that its needed.

Anyway. I think reflashing the XMEGA has fix this.

And this seems to have resolved the problem with the OpenADC constantly failing and trying again.

Also the scope display now has meaningful data

I've tried switching back to the development branch, but I get the same problems as before.

One thing I have noticed as well, is that with the development branch, that if I use the Simple Serial connect script, the red LED next to the FPGA stays on, and the green LED flashes constantly

However if I go back to 3.2.0 and load the AES SimpleSerial XMEGA script, the FPGA blue and red LEDs flash briefly and then it just goes back to flashing green next to the FPGA

I'll need to look at the docs to see what the meanings of those LED's are, but its definitely behaving differently loading the connect simple serial script in 4.0.1 than the AES SimpleSerial XMEGA script using version 3.2.0

I think I will stay with version 3.2.0 as things seem to work, whereas V4.0.1 is problem for me, especially as all the docs are written for V 3.2.0

[colinoflynn]

Hmm - 4.0.1 should work as well, not sure why! If the red LED is on, that sounds like the ADC frequency wasn't being set. WHen you run the "setup" script do you remember if things worked?

BTW if you are using the sphinx-based docs those are deprecated - we no longer mirror them, but there was some old versions out there done by others (chipwhisperer.readthedocs.io is not our site for example). Everything is now on wiki.newae.com, which is mostly 4.0.1.

[colinoflynn]

*Things worked = things happened, sorry early here and forgot my sentence. I meant as in if it looked like it was changing/executing instructions. Already know it didn't "work" as an outcome...

[rogerclarkmelbourne]

Colin

Which setup script do you mean ?

If I run

connect_cwlite_simpleserial.py

The debug terminal shows

INFO - Found ChipWhisperer-Lite, Serial Number = 44203120394d36433130322030313038
INFO - SAM3U Firmware version = 0.11 b0
INFO - Detected ChipWhisperer with USB ID ace2 - switching firmware loader
INFO - FPGA programmed
INFO - OpenADC Found, Connecting

However if I switch back to V3.2.0 CWCapture and run the Simple AES script I get

INFO - Running Script: ChipWhisperer-Lite: AES SimpleSerial on XMEGA
INFO - Found ChipWhisperer-Lite, Serial Number = 44203120394d36433130322030313038
INFO - SAM3U Firmware version = 0.11 b0
INFO - FPGA Configuration skipped - detected already programmed
INFO - FPGA programmed
INFO - OpenADC Found, Connecting
INFO - Finished Script: ChipWhisperer-Lite: AES SimpleSerial on XMEGA

I presume this means that the simple serial connect script is hanging at Opening the ADC ??

[colinoflynn]

The 4.x version switched to separate "connect" and "setup" scripts. The setup scripts (you can see the contents in the little window) only configure clock, I/O, etc. This solved the problem with the previous single-script solution, as it meant if you re-ran the script it reconnected everything (which you sometimes/often didn't want, and only wanted to re-setup the clock etc). There is many different scripts as the SW supports many variants of hardware, so it's not optimized for just CW-Lite usage with the integrated target.

The setup script (double-check name from https://wiki.newae.com/Tutorial_B5_Breaking_AES_(Straightforward) as I think that was updated to latest) should then configure clocks, I/O, etc.

We also just updated the SW to make the "nonetype" error more clear (it tells you the root issue, which is a non-connected scope) so hopefully this makes it more clear the 'setup' script doesn't connect.

[rogerclarkmelbourne]

Colin

Which script is supposed to be run first

When I try to run the connect_CWLite_simpleserial.py, the script does not seem to finish.

e.g. the last message in the debug window is

INFO - OpenADC Found, Connecting Not

INFO - Finished Script: ChipWhisperer-Lite:

Do I need to run something prior to the connect script, or should the connect script not be attempting to configure the ADC

I will try pulling your latest commits e.g. from the development branch into my local clone and try again.

[colinoflynn]

That mirrors what I see as well - the connect script doesn't configure the ADC. It should be "connect_CWLite_simpleserial.py" then "setup_cwlite_xmega_aes.py". The second one does the ADC configure, you can confirm the red LED should go off once that runs. You can check the ADC frequency, it should be around 29.538 MHz now.

We might have dropped the debug stuff saying the script is done, as basically once the Python console returns you know the script is done (you can see it call the 'exec' command in the console to run the script). Basically it's supposed to work similar to other python consoles in that regard...

[rogerclarkmelbourne]

OK I'll re-test, but I think it would be better if there was consistency with script saying whether they had completed.

The other thing that confused me, is that I can't reflash the CWLite unless I have run the connect script, i.e the menu options don't appear until the board is connected.

IMHO for GUI design its generally best to have menu options present all the time (same applies to buttons etc), but grey them out if they are not usable at the current time.

Otherwise it looks like they have been removed or possible moved somewhere else

[colinoflynn]

The other thing that confused me, is that I can't reflash the CWLite unless I have run the connect script, i.e the menu options don't appear until the board is connected.

Yeah, it's tricky as the menus change depending on hardware. We ended up putting them in as options that get loaded by the hardware itself, so the ChipWhisperer-Lite/Pro have programmer support, but other targets (such as SAKURA-G) don't have those menu options. There is another open issue caused by this choice however, so it might be easiest to go back to having fixed options that are just enabled/disabled...

would be better if there was consistency with script saying whether they had completed.

Added an issue, it wouldn't hurt as also good to know start/stop time sometimes (scripts could take longer to complete and would be nice to have that benchmark in the debug).

[rogerclarkmelbourne]

You seem to show / hide them, when the board is connected, so I presumed you could enable/disable them instead

But I don't have a detailed knowledge of the Windowing system you are using, or of Python in general, as I'm generally writing code in C, C++ or C# (and Javascript and PHP etc)

[rogerclarkmelbourne]

Colin

I can't see anything in the OpenADC settings panel that looks like 29.538MHz

System frequency is listed as 96Mhz and 24400 samples

ADC freq is listed as 192Mhz

Overall, it seems to be working most of the time.

i.e Run the connect_CWLite_simpleserial and then run the aes script, I get a waveform.

However, sometimes when I run it, I keep getting ADC timeouts. I've noticed someone else posted about this to the forum, so if I figure out under what conditions this happens, I'll post another issue.

FYI.

With the latest version from github, I get the following messages from python when starting CWCapture.py from the command line

D:\projects\rogerclark\chipwhispererMASTER\software>"D:\Program Files (x86)\ChipWhisperer\WinPython-64bit-2.7.13.1Zero\python-2.7.13.amd64\python.exe" CWCapture
.pyw
Exception AttributeError: "'PS2000' object has no attribute 'handle'" in <bound method PS2000.__del__ of <picoscope.ps2000.PS2000 object at 0x000000000A10DAC8>>
 ignored
Exception AttributeError: "'PS5000a' object has no attribute 'handle'" in <bound method PS5000a.__del__ of <picoscope.ps5000a.PS5000a object at 0x000000000A1BBF
D0>> ignored
INFO:Dictionary contains zero modules
Exception AttributeError: "'PS6000' object has no attribute 'handle'" in <bound method PS6000.__del__ of <picoscope.ps6000.PS6000 object at 0x000000000A1C42E8>>
 ignored
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
Exception AttributeError: "'PS5000a' object has no attribute 'handle'" in <bound method PS5000a.__del__ of <picoscope.ps5000a.PS5000a object at 0x000000000A892F
D0>> ignored
QWidget::setWindowModified: The window title does not contain a '[*]' placeholder

However using the version of Python I already had installed on my machine (v 2.7.11)

I get less warning messages

D:\projects\rogerclark\chipwhispererMASTER\software [develop]> python .\CWCapture.pyw
INFO:Dictionary contains zero modules
INFO:Dictionary contains zero modules
WARNING:T-test inputs: no AES module found. Using pseudorandom plaintexts instead
QWidget::setWindowModified: The window title does not contain a '[*]' placeholder

I suspect I'm missing a python crypto module from my main installation, so I'll see if I can figure out what I need to pip install....

[colinoflynn]

Hmm.. if the ADC is running at 192 MHz it seems the "setup" stuff didn't take (I'm talking after you have run the 'setup_cwlite_xmega_aes.py' script). The default power-on is 192 MHz, which is some invalid frequency basically.

Do you see any INFO/error messages when running the 'setup_cwlite_xmega_aes.py' script?

[rogerclarkmelbourne]

Hi Colin

I just re-tested, after running the AES setup script and the ADC freq is now 29.538Mhz

I could have sworn that I looked at this yesterday and it wasn't getting configured, but I must have been wrong.

I did seem to be getting some connectivity issue, yesterday, but that may have been because I've currently got 3 different versions installed on my machine.

The files installed by the V4.0.1 release exe The clone of your master repo, which includes the pushes you made 2 days ago and another clone which I have switched back to the 3.2.0 tag, so that it looked more like the documentation in parts of the wiki

I think you may as well close this issue now, and if I get to the bottom of why this was failing over the last couple of days, I'll try to document the cause and a solution.

Thanks again. PS. I see my issue about the missing Python module has been accepted as a bug and will be fixed in the next release... Thanks...

[colinoflynn]

Alright glad things are working it sounds like! Also issues #159 and #160 came out of this too and were fixed, which hopefully clear up some of the issues. And I think perhaps might have led us towards the preferred way (from user perspective) for solving #139. So if nothing else this will hopefully be more clear in the future for others!

[rogerclarkmelbourne]

Thanks Colin

I'll pull the changes for the INFO messages

Thanks again

Roger