Support EMFI campaigns in the TUI and wait for HV charge on arm - #4
Merged
Conversation
The `emfi arm` command previously only initiated HV charging, but the hardware reached the `CHARGED` state asynchronously. Attempting to `fire` before the capacitor was fully charged resulted in a misleading `INTERNAL` error. This change introduces polling of the EMFI module's status after `arm` is called, waiting until the `EmfiState` is `CHARGED` or an error/timeout occurs. This ensures that when `arm` reports success, the module is genuinely ready for a subsequent `fire` command. A `--charge-timeout-s` option is added to configure the maximum wait time.
Adds the capability to run full campaign sweeps using the EMFI engine from the TUI, mirroring the functionality previously limited to the crowbar engine. This change refactors the TUI's connection management to allow CDC0 to be shared between the EMFI status client and a new EMFI campaign client via `SharedSerial`. This is consistent with how CDC1 is shared for crowbar campaigns. The active campaign engine is now selected in the modal, determining which CDC is used for polling, start, stop, and drain operations.
…d clarify HV confirm requirements
Moves the logic for rendering status fields into `(key, value)` pairs and campaign results into single lines to their respective protocol objects. This centralizes display formatting, reducing duplication between the CLI and TUI, and simplifies the addition of new status fields.
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds EMFI-engine campaign support to the TUI, makes the
emfi armcommand wait for the high-voltage capacitor to finish charging, and
centralizes status/result formatting shared between the CLI and the TUI.
It also bumps the version to 1.0.1.
Changes
EMFI campaigns in the TUI
Previously the Campaign panel only supported the
crowbarengine (CDC1).Now both engines are supported:
crowbarruns the sweep over CDC1emfiruns the sweep over CDC0CDC0 is now shared between the EMFI status/control client and a new
emfi-engine
CampaignClientthrough aSharedSerialwrapper (mirroring theexisting CDC1 crowbar+campaign sharing). The active engine is pinned when
Configureis applied in the Campaign modal, and the live panel, hotkeys(
sstop), and start/stop/drain all follow it. This matches the CLI'scampaign --enginebehavior, where the firmware infers the engine from theCDC the command arrives on.
emfi armwaits for HV chargearmonly kicks off HV charging on the firmware; the state machine reachesCHARGEDasynchronously. Firing before that returned a misleadingINTERNALerror.
armnow pollsstatusuntil the cap is actuallyCHARGEDbeforereporting success, with a configurable
--charge-timeout-s(default 10s).Centralized status/result formatting
Added
as_rows()toEmfiStatus,CrowbarStatus, andCampaignStatus, andrender_line()toCampaignResult, as a single source of truth for display.The CLI status tables and the TUI panels now share this, so a new status
field only has to be added in one place.
Version bump
Bumped to
1.0.1across the CI workflows, Debian control, macOS buildscript, and the Windows installer.