Success report: What to do in order to get the latest version of the tutorials from git up and running with CWNano

… Hi Colin, Hi all,

… meanwhile, I got further and succeeded in running a large fraction of the tutorials with the Nano board that you gave me at Nurenberg.

Important sub-steps for getting the nano device running with current (03/17/2019) version of the 5.0 git branch:

1.) In order to connect to the CWNano, the line for assigning the scope object needs to get cw.scopes.CWNano as parameter:

import chipwhisperer as cw
scope = cw.scope(cw.scopes.CWNano)
target =

In order to make the ARM-MBED project for AES with 32 bit tables fit into the target, I needed to add the following compile switches to the Makefile:

CDEFS += -DMBEDTLS_AES_ROM_TABLES -Os -ffunction-sections -fdata-sections

… (I did somewhat misuse the CDEFS variable also for the gcc compile switches since I did not find the documentation which variable to use for optimimizer and compiler flags). Maybe it would be an option to add that to some definitions in the HAL subdirectory (did not completely re-engineer the build system so far…)

The disconnect option does not seem to work properly with the Nano device.? Possibly this is a bug somewhere within the scope’s python classes? In order to work-around this problem, it is possible to to just disconnect the hardware from the USB interface. Then it is possible to re-connect.

With the current git state of the 5.0 alpha-pre-release storing and loading acquired traces in a file does not seem to work properly. I always had to acquire fresh traces.

I had done some experiments with different initial configurations of the target. My (which worked with present .git head state) file now reads:

scope.adc.clk_freq = 7370000 = 7370000
scope.adc.samples = 5000 = “serial_rx” = “serial_tx”

I currently still don’t know exactly at which clock the ADC is operating and what clock source is used. I think that the victim is working with the clock of the ADC, but possibly it is the other way round and the ADC working with the external clock provided by the victim board? It seems that the victim’s clock is output on one of the external port lines.

For linux hosts, within the 99-newae.rules file, it is necessary to add the follwing line (with the ace0 device) in order to enable the USB hardware access also for the nano device.


SUBSYSTEM==“usb”, ATTRS{idVendor}==“2b3e”, ATTRS{idProduct}==“ace0”, MODE=“0664”, GROUP=“plugdev”

As beginner with the Nano devices and the new jupyter-based environment, I am having the following feedback:

1.) I got along quite well after having installed jupyter and gcc successfully on my linux box. I did not use the VM version, because that seems to add some siginificant additional complexity for getting access to the host’s USB devices. It might be that for many linux users this is actually the faster approach than using the VM. (It might be helpful here to have some basic jupyter and arm-none-eabi-gcc projects for testing the installation seperately, possibly two initial notebooks.)


In order to make things easier for beginners only having a nano board, it might be an option to consider to have a separate set of jupyter notebooks containing the initiial tutorial scripts and configurations for the CWNano.


Possibly, one might consider to check in (into Git) some working versions of the basic tutorial’s hex files, e.g. simpleserial-aes-CWNANO.hex. This way one could proceed even if the gcc toolchain or the newlib configuration has some problems. (There are currently some issues with the newlib multilib configuration on some ubuntu releases, e.g. 18.04. I believe that the “hard floating point” issue reported somewhere here in this forum was caused by the same issue).

Summing up, I think that with a reasonable effort one could get quite fare even with the current git version of the 5.0 alpha.

Still I’d appreciate some documentation regarding the PCB schematics for experiments with external victim boards. Notably:

Is the analog ADC input AC coupled or DC-Coupled? At which position is the trigger signal expected for the ADC? (It seems that the ADC could be “armed”, such that the ADC is then waiting for a low-high transition on some trigger line in order to start with the acquisition).
Is it possible to feed in an external victim’s clock to the ADC?

I think that the CWNano is perfect for getting a first impression and experience with actual side-channel attacks. Without the nano device I likely would not have gone this far. Might be a good choice for introductory student courses at university or as basis for in-house trainings for software developers.



1 Like

Hi Björn,

Thanks for the feedback regarding the CW Nano. Unfortunately, I don’t have a CW Nano on hand to test with, but I’ll do my best to answer your questions anyways.

I can see how it’s not super clear in the beginning tutorial. I’ll update PA_Intro_1 to better explain this.

Good catch. Out of curiosity, does TinyAES work as is? The suggestion to include binaries for different targets (at least for one or two of the basic tutorials) seems good, since that will let people at least get the hardware up and running.

Didn’t realize that. I’ll create an issue on our Github once I can confirm it.

This should be fixed in the newest commits.

adc.clk_freq should be the clock for the ADC and io.clkout should be the clock that the target uses, though you could be right that they’re switched.

Could’ve sworn that I had already fixed this :). It should be all fixed up now.

Yeah, just doing a manual install is probably going to be the recommended way to do things on Linux.

I believe the current plan is to have most of the hardware specific stuff on the wiki instead of in the notebooks, since it would be pretty hard to have tutorials on each possible scope/target.

I’m not sure what the current plan/situation is regarding the schematic for the nano. I’ll need to check with Colin. I’ll let you know once I find that out.

Thanks for the feedback,