Husky: Trigger external MOSFETs with Glitch Out MCX or Aux MCX

[lukash]

Hello!

I want to experiment with different MOSFETs for Crowbar glitching. I kind of described “issues” I’ve been having when comparing CW Lite vs. CW Husky here - it just happens my specific situation would want different MOSFET(s) it seems (like what CW Lite used to have).

I am playing with an idea to make an external board with a couple MOSFETs and trigger them using Glitch Out MCX to not have to replace MOSFETs inside of the Husky.

I have a couple concerns:

1. During regular Husky built-in MOSFET glitching one calls scope.io.vglitch_reset() to “reset the logic to make sure nothing stuck high” - I never fully understood how this works exactly or what purpose does it serve. But it worries me that I won’t quite be able to do that if I just use Glitch Out MCX directly. Can someone explain the details of this please?
2. Is there a problem with triggering an external MOSFET or potentially multiple (2) external MOSFETs using the Glitch Out MCX signal directly? If so, any suggestions to overcome that?
3. Is there a difference between Glitch Out MCX and Aux MCX with HS2 routed to it, with HS2 being configured to “glitch”? I tried playing with it and did not see a difference but not sure if there is one internally.

An extension of this idea is to use something like MAX4617/MAX4618/ MAX4619 family driven by UserIO from the Husky to enable/disable different MOSFETs on the external board that are triggered by Glitch Out MCX signal.

Any other ideas to try out other MOSFETs for Crowbar glitching without Frankensteining a Husky are more than welcome!

Thank you!

[Alex_Dewar]

@lukash

During regular Husky built-in MOSFET glitching one calls scope.io.vglitch_reset() to “reset the logic to make sure nothing stuck high” - I never fully understood how this works exactly or what purpose does it serve. But it worries me that I won’t quite be able to do that if I just use Glitch Out MCX directly. Can someone explain the details of this please?

This is to work around an issue where the Lite’s MOSFETS could get stuck on. There’s no need to do this for Husky. All this is doing is toggling the glitch module’s connection to the MOSFETS off and on again.

@lukash

Is there a problem with triggering an external MOSFET or potentially multiple (2) external MOSFETs using the Glitch Out MCX signal directly? If so, any suggestions to overcome that?

This is a bit of a tricky question. Depending on what your requirements are for slew rate and voltage, you may want additional driving and proper termination for the signal. If you can properly drive your MOSFETs at 3.3V, you could give just a straight signal a try.

@lukash

Is there a difference between Glitch Out MCX and Aux MCX with HS2 routed to it, with HS2 being configured to “glitch”? I tried playing with it and did not see a difference but not sure if there is one internally.

I’m pretty sure these are the same, but @jpthibault should be able to confirm.

[jpthibault]

@lukash

Is there a difference between Glitch Out MCX and Aux MCX with HS2 routed to it, with HS2 being configured to “glitch”? I tried playing with it and did not see a difference but not sure if there is one internally.

There is no difference.

[lukash]

@Alex_Dewar

This is to work around an issue where the Lite’s MOSFETS could get stuck on. There’s no need to do this for Husky. All this is doing is toggling the glitch module’s connection to the MOSFETS off and on again.

@Alex_Dewar Thank you, that is very helpful, I found a bit more info in the Errata of CW-Lite. I am assuming this was something in the FPGA on CW-Lite that caused those outputs to remain high (If you happen to know/remember)?

[Alex_Dewar]

Yeah, it’s some sort of bug in the FPGA.