newaetech / chipwhisperer-husky-fpga Goto Github PK

When multiple triggers are generated over the course of a capture (either from the target, or by a Husky trigger module like SAD), and scope.adc.offset is non-zero, unlucky combinations of ADC capture parameters and trigger events can result in the trigger module getting stuck: subsequent captures will fail with this message:

(ChipWhisperer Scope WARNING|File _OpenADCInterface.py:623) Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid. Status: 10
WARNING:root:Timeout happened during capture

even though the trigger events are occurring. A full reset of Husky is then required to get functioning captures again.

Some conditions have to be met in order for the bug to pop up:

1. multiple triggers must occur during the capture of a single segment (e.g., scope.adc.samples = X and a trigger event occurs every < X samples This is not a normal setup for segmented capture.
2. scope.adc.offset must be greater than 0 (the greater it is, the more likely the bug will be triggered).
3. The ADC capture must finish in the window where a trigger has come in and the offset counter kicked off by that trigger has not reached scope.adc.offset yet.

This sounds complicated but what it boils down to is that you don't need to worry about this bug unless you have scope.adc.segments=1, scope.adc.offset > 0, and multiple trigger events during your capture, where the first trigger kicks off the capture and subsequent ones are ignored since scope.adc.segments = 1.

A fix is forthcoming.

If the trigger is active prior to arming the scope, a glitch may not be issued until the next arming event. This "missing glitch" scenario occurs if the trigger from the previous glitch generation event had remained high.

Additionally, when the trigger is active prior to arming the scope, the glitch will be issued immediately upon arming the scope (except for the "missing glitch" scenario noted above). This is different from the CW-lite/pro behaviour, which did not issue a glitch until the rising edge of the trigger.

Credit to Lennert Wouters for finding the issue.

Streaming captures can fail with "slow FIFO underflow" and "fast FIFO overflow" errors when the sampling clock is < 10 MHz.

The failure occurs because the Xilinx FIFO (from which ADC samples are read) declares an underflow when it is actually nowhere near empty (internal FIFO read/write counters show that it's well over half full).

The reason seems to be that this FIFO was configured with a read clock of 96 MHz (which is accurate) and a write clock of 200 MHz (which is the fastest possible write clock, but could actually be as low as 5 MHz); it appears that the FIFO can misbehave when its read/write clock ratio is "too different" from what was specified.

A fix is in the works.

In the meantime there are workarounds:

• The simplest workaround is to simply increase the ADC sampling clock to 10 MHz or more. Extensive testing has been done at those sampling rates; additionally, the micro-ecc notebook series does streaming captures at 10 MHz, and the CW305 ECC series uses 15 MHz.
• The next simplest workaround is to increase the ADC sampling frequency by increasing scope.clock.adc_mul. This results in larger traces, but allows the target clock to stay the same.
• Another option involves tweaking the scope.adc.stream_segment_size and scope.adc.stream_segment_threshold parameters. These dictate the burst read size and default to 65536; reduce them (keeping both settings equal) until you get a clean capture. 8192 seems to work well with a sampling clock from 5 MHz to 9 MHz.

The pattern length for UART (and trace) triggering is currently fixed at 8 bytes.
That is, if you set a pattern match as follows:
scope.UARTTrigger.set_pattern_match(0, 'p00')
then the trigger will not fire until Husky sees p, 0, 0, and 5 more valid bytes (which could be anything).
If Husky only sees p00 followed by silence, then it won't trigger.
(Rationale: this made sense for trace since trace messages are always longer (if I remember correctly!))
For generic UART, it would be useful to specify the pattern length; in the example above, if the length was set to 3, then Husky would fire a trigger immediately after seeing p00.

The FSM inside trigger_resync.v module, which is involved in generating glitches, can sometimes get stuck in the DONE state, which prevents further glitch generation.
This can be verified by reading scope.glitch.state (which should normally return "idle").
This is likely caused by newer code related to mulitple glitch support (6aaf5bf).
A possible workaround is to reset the FSM manually via scope.glitch.state = None prior to every glitch event.

When using the SAD, UART, edge count, trace, or ADC level as a trigger for glitching (i.e. scope.glitch.trigger_src is set to ext_single or ext_continuous), glitches are not always generated.

There are no known issues with triggering an ADC capture from these triggers - only in their use for glitching.

Credit to Lennert Wouters for finding the issue.