CW5 Jupyter Notebook Error on Capture


I used to acquire power traces using CW4 Capture GUI, and recently decided to switch to CW5, which is more cool.

Without any changing(except for passwords), I followed the Jupyter notebook tutorial(below) to capture the
power traces using both CW1173 and CW1200, and I almost exhausted.
The problem is that the target(CW308-STM32F4) didn’t send ack when I type the following:

’ >>> target.simpleserial_write(‘k’, key)
’ >>> target.simpleserial_wait_ack()
’ ERROR:root:Target did not ack

It seems like the scope and the target are not connected.
What do you think is the problem?

The host PC is Win10 x64 and the guest PC is on VirtualBox for booting the CW5 image uploaded Release page(

I am so sorry for frequent asks.
Best regards, Park


Have you changed PLATFORM at the top of the page to be "CW308_STM32F4" instead of "CWLITEARM"?


Yes. I’m sure that I made a hex file with correct options.
After I program this firmware to the target using ST-Link, there was no error.

Indeed, when I use CW4 Capture GUI, that firmware is work properly.
However, when I use CW5 Jupyter, target doesn’t ack.
I think this is not the problem of compile options…

cd …/hardware/victims/firmware/simpleserial-base-lab1

'>>> import chipwhisperer as cw
'>>> scope = cw.scope()
'>>> target =
'>>> ktp = cw.ktp.Basic()
'>>> key, text =
'>>> target.simpleserial_write(‘k’, key)
'>>> target.simpleserial_wait_ack()
ERROR:root:Target did not ack
'>>> driver = target.ser
'>>> driver.connectStatus
'>>> driver.terminal_inWaiting()
'>>> driver.terminal_read(58)
[[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘x’],[‘out’, ‘k’],[‘out’, ‘2’],[‘out’, ‘b’] …
'>>> ret = cw.capture_trace(scope, target, text, key)
ERROR:root:Ack error:
WARNING:root:Timeout in OpenADC capture(), trigger FORCED
WARNING:root:Timeout in OpenADC capture(), trigger FORCED
/home/vagrant/work/projects/chipwhisperer/software/chipwhisperer/ UserWarning: Timeout happened during capture
warnings.warn(“Timeout happened during capture”)

It is doubtful that timeout in OpenADC capture() should be caused by unsynchronization between scope and target for some reasons.


Thank you for your time.
Best regars, Park.

Hi Park,

Can you try increasing the baud rate on both the target side and the software side to something like 115200 baud? Also, can you try writing your plaintext using target.simpleserial_write() without doing the key write and seeing if anything is sent back?


Thank you for your reply.

First, I tried to increase the baud rate to 115200.
Specifically, I made a little change as following:
In stm32f4_hal.c, UartHandle.Init.BaudRate = 115200; and
in python console, target.baud = 115200.
However the situation was not changed.

Second, I wrote a plaintext using target.simpleserial_write('p', text), with baud rate 115200.
Python console sent nothing, as you can see the above picture.
When I further type target.simpleserial_read('r', 16), the error occurs, saying ‘Unexpected start to command’.

So… any more recommendation?

I wonder why CW1200 doesn’t work although it works at CW4 with default settings. :frowning:
I hope I could my works with CW5 as soon as possible. :slight_smile:

I look forward to your response.
Best, Park.

PS) This is a evidence that CW4 is working perfectly for simpleserial-aes.c at the same condition.


I found the related post on GitHub.

Maybe this is the same problem as me.
So I’m going to change these lines.

  1. -> Decrease block_size to 16 in writeMemory(), readMemory(), and verifyMemory()
  2. -> Increase the delay to 0.000001 instead of 0.0000001.

However, I couldn’t find the delay in

def write(self, data):
    Send data to serial port.
    # print "%d: %s" % (len(data), str(data))
        data = bytearray(data)
    except TypeError:
            data = bytearray(data, 'latin-1')
        except TypeError:
            #Second type-error happens if input was already list?
    datasent = 0
    while datasent < len(data):
        datatosend = len(data) - datasent
        datatosend = min(datatosend, 58)
        self._usb.usbdev().ctrl_transfer(0x41, self.CMD_USART0_DATA, 0, 0, data[datasent:(datasent + datatosend)], timeout=self.timeout)
        datasent += datatosend

Thanks, Park.

Oh, sorry.

I noticed your recent code at

I will try and tell you the result.

Thank you. Park.

Hi Park,

Which version of arm-none-eabi-gcc do you have? Unfortunately, there seems to be a issues with many of the released builds of the compiler. Can you try installing build 5.4.1 20160919 of arm-none-eabi-gcc?


Yes, the version of the arm-none-eabi-gcc is exactly, which was installed by default in the Virtual Box image.
This problem only occurs when I use CW308_STM32F4 target board whether the scope I use is CW1173 or CW1200.
When I change the target board to CW308_XMEGA, no error occurs.

I hope I could contribute your products.
Best regards, Park.

Hi Park,

Make sure that the virtual machine is using xHCI (USB 3) as its USB controller. Also, if you’re running the ChipWhisperer off a USB Hub or USB adapter (say USB-C to USB3.0) try removing it or trying another hub/adapter.



I checked USB settings again but there was no problem.

In, I added a delay of 0.000001 at the end of the loop of read() method, not at the end of the write() method. In this way, I could flash simpleserial-aes-CW308_STM32F4.hex to CW308_STM32F4.



However, this was not sufficient to solve the original problem, calling capture_trace() sends a error saying target did not ack.
So, similar to the previous solution, I made same changes at the end of the loop of both write() and flush() methods.



Having done, I finally succeeded to acquire the trace of the target.


I think these temporary solutions are not perfect, so It is not strange when it breaks down.
For example, the amount of time.sleep should be adjusted delicately.
In the cases of 0.00001 or 0.0000001, It would not work properly.

***** IN CONCLUSION, *****

  1. change baud rate to 115200 on both the target side and the software side.
  2. add delay 0.000001 to the end of the while loop at write(), flush(), read() in

Thank you for your time and grateful consideration.
I wish my long long postings give some inspiration to the developers of CW hardware.

Hi Park,

Good to hear you were able to fix this! There was some changes made to USB comms for v5. I believed we had ironed out most of the bugs, but apparently I was wrong! I’ll investigate further soon.


So I was able to recreate this on my home computer (both Linux and Windows) and I’m seeing some very strange behaviour:

  • Programming fails at 115200 baud, but works with both 38400+small_blocks=False and 115200+small_blocks=True
  • On Linux, if programming with small blocks (but not 38400+no small_blocks) capture will work afterwords at a heavily reduced speed (roughly 7 captures/second versus 40 captures/second with work laptop)
  • On Windows, neither works

I’ll try experimenting more and seeing if I can figure out where this behaviour’s coming from. @djpark if you’re still around, do you mind posting the specs of your computer?


Possibly related to:


Sorry for late response.
Here is my host and guest pc specs:

Host PC

  • Intel i7-8700K @ 3.70 GHz
  • Samsung DDR4 16 GB (x3)
  • Nvidia RTX 2080
  • Microsoft Windows 10 Enterprise 64-Bit

Guest PC

  • 4 processors
  • 8192 MB Memory
  • ChipWhisperer Jupyter Image from GitHub.

Hi Park,

Thanks for responding. I’ve got a Ryzen 2600 machine at home that also has this behaviour. I’ve got a PCIe usb card on the way.

One additional question: when you got the device working, what sort of capture speeds do you get? Is it up in the 40cap/s range, or lower (or maybe even higher)?