Help understanding batchRun in naeusb

Embedded Security ChipWhisperer Software
1

Hi,

I’m looking at the batchRun function to speed up measurements on the CW305. I’ve deduced that the python batchRun() call ends up here: naeusb/naeusb_fpga_target.c at 09c6ed86c40f762316670dc9f26b8bf7f67153ff · newaetech/naeusb · GitHub

on the microcontroller. I am testing this function on the AES example bitstream with a picoscope

A few questions:

I noticed that when this function is called my scope does not capture the trigger for each encryption, where as if I trigger a manual encryption with fpga_write then it does work. Is it because the function sets: gpio_set_pin_high(FPGA_TRIGGER_GPIO);? Why set the trigger from the microcontroller instead of from the target?

2

In this case, the IO pin is triggering the FPGA to run AES. This is done to avoid noise from communication lines between the microcontroller and the FPGA. There’s a separate FPGA trigger pin that ChipWhisperer is triggering off of.

Are you using an external oscilloscope for capturing, or a ChipWhisperer?

3

Yes, I am using an external oscilloscope for capture and with batchRun it doesn’t detect the trigger. I have my scope trigger set to watch TP4. From my understanding it should work regardless of scope, right? Since the fpga design sets tio_trigger

4

@Alex_Dewar

It seems that this function doesn’t work at all. I built the bitstream with Vivado 2024.2 using the AES code from the CW repository. My CW305 is on firmware version 0.53, which seems to be the latest FW.

Here is a code-snippet I am using to

test:cw305.fpga_write(cw305.target.REG_CRYPT_KEY, key[0])

key, pt = cw305.batchRun(batchsize=1)

logger.info(cw305.fpga_read(cw305.target.REG_CRYPT_KEY, 16).hex())

logger.info(key)

logger.info(pt)

output:

2025-12-03 13:51:20.180 | INFO | main:main:152 - 00000000000000000000000000000000
2025-12-03 13:51:20.180 | INFO | main:main:153 - [[3, 177, 129, 54, 250, 205, 206, 31, 236, 175, 117, 197, 245, 122, 19, 135]]
2025-12-03 13:51:20.180 | INFO | main:main:154 - [[170, 238, 132, 51, 170, 85, 80, 177, 240, 142, 158, 103, 161, 68, 145, 74]]

So clearly the key is not being written with batchRun and I guess it’s not receiving the start GPIO command.

5

Yes, we are looking into this. This is contributed code so it may take a bit longer to figure out why and how it is broken.

6

Ok, thanks for the update.

I just tested with firmware built from the latest cw305_artix_target commit and the latest naeusb commit and can confirm it’s also broken there.