Hi Greetings,
I wanted to physically capture the traces for the “SCA 204” course in jupyter notebooks. But unfortunately, I run into this warning while capturing traces.
This is the command, I am trying to run: traces = get_traces(1, k, ‘part1_1’, full=True)
These are the warnings: ChipWhisperer Scope WARNING|File _OpenADCInterface.py:695) Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:695) Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid
(ChipWhisperer NAEUSB WARNING|File naeusb.py:1047) Streaming: USB stream read timed out
(ChipWhisperer NAEUSB WARNING|File naeusb.py:1047) Streaming: USB stream read timed out
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:957) Unexpected sync byte in processData(): 0x0
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:957) Unexpected sync byte in processData(): 0x0
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:804) Stream mode: done, no samples resulted from processing
(ChipWhisperer Scope ERROR|File OpenADC.py:826) Received fewer points than expected: 0 vs 1130000
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:804) Stream mode: done, no samples resulted from processing
(ChipWhisperer Scope ERROR|File OpenADC.py:826) Received fewer points than expected: 0 vs 1130000
(ChipWhisperer Target WARNING|File CW305_ECC.py:141) Timeout happened during capture
(ChipWhisperer Target WARNING|File CW305_ECC.py:141) Timeout happened during capture
Failed capture
Failed capture
Without any capture, the noteboook only gives more warnings.
I am using the CW1200 with CW305 FPGA.
I have looked at the other posts and tried following those, but it did not make a difference. Any help would be appreciated. Thank you. Let me know if any more data is required.
Yes, there was no errors or warnings prior to this. I am following the exact notebook in SCA 204 . This experiment is CW305_ECC_part1.ipynb.
My target is TARGET_PLATFORM = ‘CW305_100t’
And platform, PLATFORM = ‘CWPRO’
Traces, TRACES = ‘HARDWARE’
Have you set J16 and K16 as instructed? Yes I followed this.
There are no prior errors while running.
LED8 is solid green
LED7 flashes red and LED5 flashing green ( next to each other)
A solid red at the FPGA - LED 1, I guess.
LED1, which is next to the Atmel chip (not the FPGA) should be flashing red, not solid red - otherwise everything seems fine. Are you sure it’s not flashing?
Did you connect the 20-pin cable between the CW305 and the CW-Pro?
What is the output of print(target)
?
Yes That’s right, LED 1 is flashing red.
I have connected the 20 pin cable between the CW305 and CW pro, and a SMA cable.
This is the output of the print(target):
target_name = Cryptech ecdsa256-v1 pmul
fpga_buildtime = 10/20/2023, 09:05
core_type = ECC
crypt_type = 3
crypt_rev = 0
platform = cw305
REG_CRYPT_GX = 9
REG_CRYPT_GY = 10
REG_CRYPT_K = 6
REG_CRYPT_RX = 7
REG_CRYPT_RY = 8
REG_CRYPT_GO = 5
REG_USER_LED = 1
REG_BUILDTIME = 11
REG_CRYPT_TYPE = 2
REG_CRYPT_REV = 3
REG_IDENTIFY = 4
REG_BRAM_RD_MSB = 12
REG_LFSR_GO = 13
REG_LFSR_STATE = 14
REG_LFSR_RD = 15
REG_LFSR_RD_BANK = 16
REG_NOISE_ENABLE = 17
REG_KB = 18
REG_RB_SELECT = 19
Everything looks normal; I can’t reproduce your issue.
Make sure you haven’t modified the notebooks (both CW305_ECC_part1.ipynb
and CW305_ECC_setup.ipynb
) and try again.
I never changed the notebooks. Do I have to load the bitfile for ecc before trying to capture using the hardware?
The notebook does this for you. I can see that the bitfile has been programmed correctly from the print(target)
output, and that the target is responding. Which is why it is very strange that the capture is failing.
Could there be a problem with the firmware on target. I learnt that the issue is due to the target not triggering.
With a logic analyzer or oscilloscope, you can check whether your CW305 is driving the trigger line: connect a probe to the “TRIG” header on the lower right corner of the CW305.
Then, see whether target.usb_trigger_toggle()
causes it to pulse high for approximately 100ms.
Hi, an update on the issue.
I tried to run the attack with different device( the CW1200 and the CW 305), I was able to run the attack with no issues.
Later, I tried using the same CW305 that I had originally, but with a different capture device(the CW1200), I was once again able to successfully run the attack.
But the issue persists while using the CW1200 that I originally had.
So I believe there is a problem with the scope rather than the target board.
Here are the outputs for the print(scope).
This is the output from the CW1200 with the issue:
cw1200 Device
sn = 50203120355448513230343238313033
fw_version =
major = 1
minor = 62
debug = 0
gain =
mode = high
gain = 38
db = 29.9921875
adc =
state = False
basic_mode = rising_edge
timeout = 2
offset = 0
presamples = 0
samples = 1130000
decimate = 1
trig_count = 1124157
fifo_fill_mode = normal
stream_mode = True
clock =
adc_src = extclk_x1
adc_phase = 0
adc_freq = 10000419
adc_rate = 10000419.0
adc_locked = True
freq_ctr = 10000408
freq_ctr_src = extclk
clkgen_src = system
extclk_freq = 10000000
clkgen_mul = 2
clkgen_div = 26
clkgen_freq = 7384615.384615385
clkgen_locked = True
trigger =
triggers = tio4
module = basic
aux_out = False
io =
tio1 = serial_rx
tio2 = serial_tx
tio3 = high_z
tio4 = high_z
pdid = high_z
pdic = high_z
nrst = high_z
glitch_hp = False
glitch_lp = False
extclk_src = hs1
hs2 = None
target_pwr = True
tio_states = (0, 1, 0, 0)
cdc_settings = bytearray(b’\x00\x00\x00\x00’)
glitch =
clk_src = target
mmcm_locked = True
width = 10.15625
width_fine = 0
offset = 10.15625
offset_fine = 0
trigger_src = manual
arm_timing = after_scope
ext_offset = 0
repeat = 1
output = clock_xor
SAD =
threshold = 0
reference = [0]
decode_IO =
trigger_pattern = None
rx_baud = 38360.23667279412
decode_type = USART
And here is the print(scope) from the CW1200 without issue:
I will upload the rest as only a single upload is permitted.
The only difference I found was in the frequency, could that cause the issue?
- Sorry, what is the frequency difference? I don’t see it.
- Instead of screen shots, please copy/paste as text, and in this case, please use the “</>” aka “preformatted text” button in the forum so that the formatting is retained and it’s easier to read. Thanks in advance - it’s a lot easier for us to help you if the information is presented more clearly.
- To be clear, exactly what is different between the setup which works and the one which doesn’t. Just the CW1200? Are all cables, connectors, host PC, and ChipWhisperer installation the same?
- If you have some other NewAE target (other than the CW305), try using the suspected bad CW1200 with that target.
Please answer all the questions so that we can get to the bottom of this sooner.
Sorry for the delayed response, I didn’t have the device to retry again.
Here is the print(scope) for the faulty one,
<
cw1200 Device
sn = 50203120355448513230343238313033
fw_version =
major = 1
minor = 62
debug = 0
gain =
mode = high
gain = 38
db = 29.9921875
adc =
state = False
basic_mode = rising_edge
timeout = 2
offset = 0
presamples = 0
samples = 1130000
decimate = 1
trig_count = 1124157
fifo_fill_mode = normal
stream_mode = True
clock =
adc_src = extclk_x1
adc_phase = 0
adc_freq = 10000408
adc_rate = 10000408.0
adc_locked = True
freq_ctr = 10000419
freq_ctr_src = extclk
clkgen_src = system
extclk_freq = 10000000
clkgen_mul = 2
clkgen_div = 26
clkgen_freq = 7384615.384615385
clkgen_locked = True
trigger =
triggers = tio4
module = basic
aux_out = False
io =
tio1 = serial_rx
tio2 = serial_tx
tio3 = high_z
tio4 = high_z
pdid = high_z
pdic = high_z
nrst = high_z
glitch_hp = False
glitch_lp = False
extclk_src = hs1
hs2 = None
target_pwr = True
tio_states = (0, 1, 0, 0)
cdc_settings = bytearray(b’\x00\x00\x00\x00’)
glitch =
clk_src = target
mmcm_locked = True
width = 10.15625
width_fine = 0
offset = 10.15625
offset_fine = 0
trigger_src = manual
arm_timing = after_scope
ext_offset = 0
repeat = 1
output = clock_xor
SAD =
threshold = 0
reference = [0]
decode_IO =
trigger_pattern = None
rx_baud = 38360.23667279412
decode_type = USART
/>
The print(scope) from the working scope:
<cw1200 Device
sn = 50203120355448513030343230313034
fw_version =
major = 1
minor = 62
debug = 0
gain =
mode = high
gain = 38
db = 29.9921875
adc =
state = False
basic_mode = rising_edge
timeout = 2
offset = 0
presamples = 0
samples = 1130000
decimate = 1
trig_count = 1124157
fifo_fill_mode = normal
stream_mode = True
clock =
adc_src = extclk_x1
adc_phase = 0
adc_freq = 10000419
adc_rate = 10000419.0
adc_locked = True
freq_ctr = 10000408
freq_ctr_src = extclk
clkgen_src = system
extclk_freq = 10000000
clkgen_mul = 2
clkgen_div = 26
clkgen_freq = 7384615.384615385
clkgen_locked = True
trigger =
triggers = tio4
module = basic
aux_out = False
io =
tio1 = serial_rx
tio2 = serial_tx
tio3 = high_z
tio4 = high_z
pdid = high_z
pdic = high_z
nrst = high_z
glitch_hp = False
glitch_lp = False
extclk_src = hs1
hs2 = None
target_pwr = True
tio_states = (0, 1, 0, 0)
cdc_settings = bytearray(b’\x00\x00\x00\x00’)
glitch =
clk_src = target
mmcm_locked = True
width = 10.15625
width_fine = 0
offset = 10.15625
offset_fine = 0
trigger_src = manual
arm_timing = after_scope
ext_offset = 0
repeat = 1
output = clock_xor
SAD =
threshold = 0
reference = [0]
decode_IO =
trigger_pattern = None
rx_baud = 38360.23667279412
decode_type = USART
/>
- If you look under ADC: The adc_frequency is different.
- There is difference in the setup and connections, even the PC is the same, only change was cw1200 device.
- I do not have any other target board that is suitable for this course, only the CW305.
Thank you for your patience. Please let me know if anything else is required from me.
Ah ok. That is not an important difference and it would not be a cause for the problem you reported.
Since you don’t have other targets, try running this notebook with the “bad” CW1200: chipwhisperer-jupyter/demos/PA_HW_CW305_1-Attacking_AES_on_an_FPGA.ipynb at main · newaetech/chipwhisperer-jupyter · GitHub
The given AES attack on an FPGA runs completely fine and even captures the traces.
When the CW305_ECC_part1.ipynb
notebook fails, what is the output of print(target.pll.pll_outfreq_get(1))
?
If I set this to the wrong value, I get exactly the errors that you show at the top of this thread. One way for the PLL frequency to have the wrong value is if PLATFORM
is not set to CWPRO
. Could this be what is happening here?
The output for this command - “print(target.pll.pll_outfreq_get(1))” is <
10000000.0/>
The platform is set to CWPRO, and I use the same code for the working capture device as well, so it is set to CWPRO.
The notebook also has a command to set the outfreq , so it might not be the problem I guess.
Apologies for the delay- then I suspect that the issue is that the capture fails on the so-called “bad” CW1200 because the streaming capture fails. With CW1200, streaming is done on a “best-effort” basis and can fail due to issues outside our control, such as activity from other devices on the USB bus, or other factors on side of the host PC (such as the USB port, cable, etc).
If the “bad” CW1200 consistently fails to record stream captures, where the “good” CW1200 always works and all other variables (USB activity, port, cable, host computer) are the same in both cases, then contact sales@newae.com and we will arrange to have a look at your CW1200.