I did a small test where I set a variable and surrounded it with trigger high and low , like: trigger_high();
int x = 5;
trigger_low();
I compiled the firmware and flashed it onto the ChipWhisperer Lite XMEGA chip. I then went and took 10,000 samples. The graph was filled. How is that possible? This makes me think that the trigger_low(); call didn’t disable the scope as I expected, since just setting a variable to a value shouldn’t take so long.
Some images are here: http://imgur.com/a/nckwr. It looks like the scope just adds a bunch of noise. How can it be made to not add noise? I’ve looked through the code, and haven’t found anything that seems to be related to the scope controls or handling data coming back for the graph.
Essentially, I’d like to do numerous windowed acquisitions, like this:
void some_function() {
int i;
for(i = 0; i < 16; i++) {
trigger_high();
// Some operations I care about
trigger_low();
// Some stuff I don't care about
// Still more stuff I don't want captured
// Really don't collect traces on this code.
}
}
And I was trying to get ChipWhisperer to give me some graphs that I’d expect to see given such a limited scope.
Hi Richard,
Ah - the trigger only starts the capture, it doesn’t gate anything. Basically it’s just like a regular scopes trigger. Once the trigger occurs it will continue to capture as many data-points as you request, and it now is ignoring the trigger.
To be honest I hadn’t thought of adding ‘windows’ - it’s not a bad idea to maximize use of the small buffer. But the architecture as-is relies heavily on the “edge-sensitive” nature, for example using the “trigger valid” to start a download, as some trigger conditions are only a single cycle long (i.e., you cannot “gate” it).
The difference between rising/falling edge and “high”/“low” respectively is solely that high/low will trigger immediately if the condition is valid. So if you “arm” the scope and the trigger mode is set to “low”, and the physical trigger line is low, the scope will trigger. But if the trigger mode is set to “falling edge”, it would wait until the I/O line went high and THEN had a falling edge to trigger.
To “fix” the issue, see the file app.assembla.com/spaces/chipwhi … p_stream.v at line 254 (might move in future versions), which looks like this:
.wr_en(adcfifo_wr_en & stream_write), // input wr_en
This is the write enable for the FIFO. You might be able to add another condition that only writes while the trigger condition is still valid… this would break the rising/falling edge modes. It’s not something I’m likely to add soon, as it would require a fair amount of testing to ensure I haven’t broken things (and there’s a lot of already broken things on my todo list to fix first!).
Regards,