Husky leaks clock into other signals

I noticed that once Husky is configured, it leaks clock into other signals (like nRST, GPIOx and other pins on the header). Ribbon cable makes it more visible, but even just connecting 3.3V, GND and nRST (clock is either from crystal or internal oscillator) still shows the deformed clock artifacts on other signals (but without ribbon the amplitude is smaller).

This is more pronounced if scope.clock.clkgen_freq is 200 MHz.

I tried disconnecting/reconnecting everything and reconnecting just mininum cables, but it’s generated by Husky.

The main question is how to deal with this if your target (like STM32F4xx) is already jittery and noisy, so extra noise is not helpful. This is from Husky+CW308+STM32F415 target as example.

Description of signals for the next few examples:

  1. CH1 yellow - nRST
  2. CH2 cyan - trigger out from Husky MCX port
  3. CH3 magenta - GPIO4
  4. CH4 blue - CW501 differential probe between SHUNTH and SHUNTL

With scope.default_setup() and its 7.37 MHz clock we get nRST (CH1 yellow) that shows clock leaks into it, even though it’s in logic 1 by value, so it doesn’t reset MCU. GPIO4 (CH3 magenta) which is farther from the HS2 pin is affected less, but you can still see the pattern:

Default setup with 7.37 MHz clock

Triggering on nRST

Now if we want to use trigger (shown in CH2 cyan) on nRST, it will get a bit confused because of the nRST pattern - this would also cause the captured signals to be unaligned without later time cross-correlation:

Difference between noise with Husky 7.37 MHz clock and 200 MHz clock (chip uses internal clock)

This is boot of STM32F415 (BOOT0 selected, it goes from its internal HSI - doesn’t depend on outside clock) when 7.37 MHz clock is used:

The same boot with 200 MHz:

scope.clock.adc_mul = 1
scope.clock.clkgen_freq = 200000000

You can see that noise in CH4 from the differential probe increased significantly, which makes it harder for SAD trigger.

Reference when Husky is powered on, but not yet configured

You can see there is no noise leak among signals before Husky clock is set up:

Workaround or some sort of fix?

Do you have some workaround or fix or an idea of how to get rid of the noise? I wrote already SCPI script to catch 100-1000 waveforms and average them to average noise out (maybe do time cross-correlation before), then do the same with CW capture. Low pass filters didn’t turn out to be useful.

On the other hand, 200 MHz clkgen_freq is necessary for glitches to be close to trigger. I’m lost on what exactly to do here.

If your target doesn’t use the Husky HS2 clock, then the solution is easy! = 'disabled'

Otherwise there may not be much you can do other than reduce the clock frequency.

1 Like

Thanks, did not expect solution to be this easy!