Hi, I’m using Chipwhisperer HUSKY and trying to capture long trace with CW313 board and STM32F415. I just turn on the stream mode with scope.adc.stream_mode = True and set the samples to 1000000. Also I set scope.clock.clkgen_freq = 15e6 and scope.clock.adc_mul = 1,but I still got a USBErrorPipe error and WARNING|File _OpenADCInterface.py:605) Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid. Could any one tell me how to use the stream mode correctly and what mistake I have made?
Here is my firmware and jupyter notebook page:
Are you able to capture successfully when streaming mode is off (with fewer scope.adc.samples of course)? Just to ensure that communication with the target is working correctly, before sorting out any streaming issues.
Thank you for your reply. I’m able to capture traces with scope.adc.samples = 130000 when streaming mode is off. When stream mode is turned on, it can capture 250,000 samples at the default sampling rate, but sometimes it can capture 270,000 or even 290,000. But it usually reports error: (ChipWhisperer Scope WARNING|File _OpenADCInterface.py:605) OpenADC capture() timeout, no trigger seen! Forced trigger, invalid data
(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:622) A FIFO error occurred; see scope.adc.errors for details
Another problem is that with stream mode off, if I change the sample rate parameter directly, for example scope.clock.clkgen_freq = 7.0e6, the trace capture will also report error: Timeout in OpenADC capture(), no trigger seen! , data is invalid.
Here is my firmware, wish it could provide more information for you
When you change the target clock frequency from the default 7.37 MHz, you need to manually update the baud rate that’s used by the serial link to talk to the target. The baud rate is fixed at 38400 for a 7.37 MHz clock, so if you change the clock you need to adjust the baud rate as follows: target.baud *= 38400 * <TARGET FREQUENCY> / 7.37e6. This is probably the cause of all your problems.
Thanks for reply. I tried to adjust the baud rate as you say but I got USBErrorPipe this time.
I think I may have complicated the question. Simply speaking, how should I set up my HUSKY to capture traces of about 8M (or 4M) samples via stream mode?
Setting up Husky for streaming mode is simply scope.adc.stream_mode = True.
However performance (in terms of max sampling rate / capture size) will depend on the particulars of your PC. Having any other USB activity can have a significant impact.
However “no trigger seen” that you get is not the error you would get from streaming “too much” or “too fast”.
There may be issues with your custom firmware. I would try to first establish reliable streaming of our stock AES firmware.
According to ShinZzz, there are 2 problems, you explained the second problem(Timeout in OpenADC capture(), no trigger seen! ) .How about the first problem of FIFO error under stream mode? In scope.adc.errors, it says “slow FIFO underflow, fast FIFO overflow, ADC clipped”.
This seems to be a separate issue.
To avoid confusing things on this thread, can you start a new topic and provide more information so I can help pinpoint the problem:
- what is your target and what firmware is it running
- what is your capture script
- are you able to capture successfully when stream mode is off?
Okay, I post a new one on the forum called “problem when using stream mode”
sorry for my late response. In last few days I viewed some related topics and returned to the AES firmware for further examination. Now I can capture kyber traces with stream mode. But, here I met another issue. When I’m capturing traces, there sometimes occur some Warnings, like FIFO error occurred, Invalid CRC or Unexpected frame byte…
I just reboot the husky and restart to capture traces when I met this situation. So, if there has a better solution to solve this problem?
Here are some settings I used when capturing traces with stream mode:
scope.trigger.module = ‘basic’
scope.adc.basic_mode = “rising_edge”
scope.trigger.triggers = “tio4”
scope.io.tio1 = “serial_rx”
scope.io.tio2 = “serial_tx”
scope.clock.clkgen_freq = 10e6
scope.io.hs2 = ‘clkgen’
scope.clock.clkgen_src = ‘system’
scope.clock.adc_mul = 1
scope.clock.reset_dcms()
reset_target(scope)
scope.adc.stream_mode = True
scope.adc.samples = 2000000
target.baud *= scope.clock.clkgen_freq / 7.37e6
And here is a screen shot with the issue:
I’m glad you were able to get stream mode working.
As for the other errors, I can’t pinpoint the cause from this information, but one thing I forgot to mention is the scope.adc.timeout parameter: if the capture takes longer that scope.adc.timeout seconds to complete, you will get the “Timeout in OpenADC capture” error; if that’s the culprit, the solution is to simply increase scope.adc.timeout. Just make it so that:
scope.adc.timeout > scope.adc.samples / scope.clock.adc_freq.
If that’s already satisfied, the other errors point to a communication problem on the serial link. Instead of resetting Husky, have you tried resetting only your target?
my settings satisfy scope.adc.timeout > scope.adc.samples / scope.clock.adc_freq`
Does resetting only target mean reset_target(scope)? I only do this after I set to open stream mode.
Yes, reset_target(scope) is what I meant.
The idea is that it may be your target firmware that is misbehaving and leading to the capture errors; resetting only the target will be much faster than resetting Husky.
Of course, the proper solution is to figure out why this is happening. What I would do is:
- make sure your target firmware is in the intended state after each capture (i.e. so that it is ready to accept the commands for the next capture)
- make sure your target is responding to each capture command and raising the IO4 trigger line as expected (here an external logic analyzer would be helpful)