Very experimental and for testing only by JurajSadel · Pull Request #5201 · esp-rs/esp-hal

JurajSadel · 2026-03-17T13:07:40Z

I want to use this PR as a playground for Radio HIL. It’s very rough and messy, but I mainly want to test the infrastructure here with the simplest possible POC.

JurajSadel · 2026-03-25T09:50:07Z

/hil quick

github-actions · 2026-03-25T09:51:09Z

Triggered quick HIL run for #5201.

Run: https://github.com/esp-rs/esp-hal/actions/runs/23534885428

Status update: ❌ HIL (quick) run failed (conclusion: failure).

github-actions · 2026-03-25T18:15:14Z

New commits in main has made this PR unmergable. Please resolve the conflicts.

github-actions · 2026-03-26T11:26:47Z

New commits in main has made this PR unmergable. Please resolve the conflicts.

github-actions · 2026-03-27T09:04:56Z

New commits in main has made this PR unmergable. Please resolve the conflicts.

github-actions · 2026-03-27T12:30:52Z

New commits in main has made this PR unmergable. Please resolve the conflicts.

MabezDev

I don't think this is quite the direction I would go with.

I think its okay to have a radio-hil package. I think the testing mechanism will be sufficiently different that trying to shoe-horn it into our current hil suite will cause headaches.

As my other comment alludes to, we shouldn't be invoking binaries - let's use probe-rs directly.

JurajSadel · 2026-04-02T08:48:31Z

/hil quick

github-actions · 2026-04-02T08:49:56Z

Triggered quick HIL run for #5201.

Run: https://github.com/esp-rs/esp-hal/actions/runs/23892282626

Status update: ❌ HIL (quick) run failed (conclusion: failure).

MabezDev

Not at the point of critiquing code, my review is still conceptual and architectural at this point.

MabezDev · 2026-04-02T09:34:51Z

@@ -0,0 +1,222 @@
+#[embedded_test::tests(default_timeout = 45, executor = esp_rtos::embassy::Executor::new())]


The directory structure is a bit odd to me, I feel like mod esp_radio will have all the tests in it, so what's the point of the mod?

We should probably split these into catagories, wifi, ble etc.

MabezDev · 2026-04-02T09:44:35Z

+    }
+
+    #[test]
+    async fn wifi_ap_test(p: Peripherals) {


Do we plan on adding more test configurations here? If we do, how will that work regarding test synchronization to the other board? I.e the other board might be running tests whilst this test finishes causing the other side to fail when there is no AP available?

If this will always be one test (which doesn't really test anything, note the lack of asserts here), then I think we should write these differently. The goal of testing is to isolate and test discrete variables, therefore we should only testing on one side at any given time. If we want to test the dhcp side with this AP, this AP should be a fixed function firmware.

General rule of thumb: If we're testing STA, AP should be a fixed. If we're testing AP, then the STA firmware should be fixed, or a set of fixed firmwares to try.

MabezDev · 2026-04-02T09:50:35Z

+}
+
+/// Run a radio test on 2 devices (AP and STA)
+pub fn run_radio_test(


Based on my other comments above, I think if we make changes so that we're only testing one variable at a time, we can use the current xtask tooling for running tests, with a few modifications.

When we run xtask test with a test name, in this case wifi_dhcp (imo should be wifi_sta), our test runner should be able to find the test, then we can add metadata at the top of the file to indicate what firmware needs to run on the other side.

//% HARNESS_FIRMWARE(wifi_ap)

Something like this, so that the xtask knows how to setup the other device for this test series.

github-actions · 2026-04-02T15:01:57Z

New commits in main has made this PR unmergable. Please resolve the conflicts.

bjoernQ · 2026-04-27T09:44:01Z

 pub fn load(path: &Path) -> Result<Vec<Metadata>> {
    let mut examples = Vec::new();

+    println!("Loading examples from {}", path.display());


we probably should use log instead

bjoernQ · 2026-04-27T09:45:27Z

                    relevant_metadata.apply(|meta| meta.tag = Some(meta_line.value.to_string()));
                }
+                // Optional support firmware binary that must run on another target.
+                "HARNESS_FIRMWARE" => {


maybe we don't want to mix usage of _ and -

bjoernQ · 2026-04-27T09:47:53Z

+
+#[cfg(soc_has_wifi)]
+#[path = "esp_radio/wifi_dhcp.rs"]
+mod wifi_dhcp;


we can probably find a better name - also for the executable since esp_radio is very generic and we will need more (since different tests need a different support FW)

bjoernQ · 2026-04-27T10:06:06Z

I wonder if we always want the support-fw and the test-fw to target the same chip - but I guess that assumption should be fine

MabezDev

Overall, this is taking shape nicely, but needs some more thought on how we setup the tests and hand off the running, and then some more general polish.

MabezDev · 2026-04-27T09:58:59Z

@@ -0,0 +1,557 @@
+#[embedded_test::tests(default_timeout = 45, executor = esp_rtos::embassy::Executor::new())]


I think the parent dir should be tests, not esp_radio.

MabezDev · 2026-04-27T10:00:06Z

+        defmt::info!("[STA] TEST_DONE: PASS");
+    }
+
+    // #[test]


Please don't leave wads of uncommented code in a PR. If it's something to add later, pull it out into a gist and re-add closer to merge.

MabezDev · 2026-04-27T10:01:15Z

@@ -0,0 +1,198 @@
+//% CHIPS(has_wifi_ble): esp32c6


This should go in a support dir, adjacent to the test dir.

MabezDev · 2026-04-27T10:02:08Z

+harness           = false
+required-features = ["esp-alloc"]
+
+[dependencies]


I think many of these deps need to be bumped to match hil-test before we merge.

MabezDev · 2026-04-27T10:03:01Z

    pub timings: bool,
+
+    /// "hil-test" or "hil-test-radio"
+    pub package: Option<String>,


We should leverage claps default here, instead of the unwrap_or later.

MabezDev · 2026-04-27T10:04:41Z

+                        .apply(|meta| meta.harness_firmware = Some(meta_line.value.to_string()));
+                }
+                // Mark this artifact as support firmware (not a DUT test).
+                "SUPPORT_FIRMWARE" => {


Why two keys for the same thing?

MabezDev · 2026-04-27T10:06:00Z

+
+fn parse_bool(value: &str) -> Result<bool> {
+    match value.trim().to_ascii_lowercase().as_str() {
+        "true" | "1" | "yes" | "y" | "on" => Ok(true),


Let's just support true or false please.

MabezDev · 2026-04-27T10:14:07Z

+    let no_batch = is_radio_package && matches!(action, CargoAction::Run);
+    let built_commands = commands.build(no_batch);
+
+    if is_radio_package && matches!(action, CargoAction::Run) {


This whole section here feels quite hacky tbh - I think we should rethink this part.

I would like it so that run_radio_test just takes the name of the test binary we want to run, then behind the scenes we compile and flash the support runner, then hand back to a normal test running flow.

These new test are not any different the other hil tests, the only difference is that we have a pre step to do, which is running fw on a support device first.

JurajSadel force-pushed the wifi-hil branch from cf1cbde to c509029 Compare March 17, 2026 13:14

JurajSadel closed this Mar 17, 2026

JurajSadel force-pushed the wifi-hil branch from c509029 to 24731c5 Compare March 17, 2026 13:22

JurajSadel reopened this Mar 17, 2026

JurajSadel force-pushed the wifi-hil branch 9 times, most recently from 16ec989 to 4816b6f Compare March 17, 2026 16:21

JurajSadel force-pushed the wifi-hil branch 2 times, most recently from 2368b8e to 2cbecd3 Compare March 25, 2026 09:48

JurajSadel force-pushed the wifi-hil branch from 2cbecd3 to 427e5f2 Compare March 25, 2026 10:46

github-actions Bot added the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Mar 25, 2026

JurajSadel force-pushed the wifi-hil branch from 427e5f2 to 529984d Compare March 26, 2026 10:41

github-actions Bot added merge-conflict Merge conflict detected. Automatically added/removed by CI. and removed merge-conflict Merge conflict detected. Automatically added/removed by CI. labels Mar 26, 2026

JurajSadel force-pushed the wifi-hil branch from 529984d to 64fa891 Compare March 27, 2026 08:29

github-actions Bot added merge-conflict Merge conflict detected. Automatically added/removed by CI. and removed merge-conflict Merge conflict detected. Automatically added/removed by CI. labels Mar 27, 2026

JurajSadel force-pushed the wifi-hil branch from 64fa891 to 6b10532 Compare March 27, 2026 09:06

github-actions Bot removed the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Mar 27, 2026

github-actions Bot added the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Mar 27, 2026

MabezDev requested changes Mar 27, 2026

View reviewed changes

Comment thread xtask/src/radio_hil_runner.rs Outdated

JurajSadel force-pushed the wifi-hil branch from 6b10532 to 4c4df9b Compare April 2, 2026 08:46

github-actions Bot removed the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Apr 2, 2026

JurajSadel force-pushed the wifi-hil branch from 4c4df9b to 964c542 Compare April 2, 2026 08:47

JurajSadel force-pushed the wifi-hil branch from 964c542 to 5b5a95e Compare April 2, 2026 08:50

MabezDev reviewed Apr 2, 2026

View reviewed changes

github-actions Bot added the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Apr 2, 2026

JurajSadel force-pushed the wifi-hil branch from 5b5a95e to e6aa955 Compare April 13, 2026 13:12

github-actions Bot removed the merge-conflict Merge conflict detected. Automatically added/removed by CI. label Apr 13, 2026

JurajSadel force-pushed the wifi-hil branch from e6aa955 to ed53161 Compare April 13, 2026 13:14

JurajSadel added 3 commits April 20, 2026 14:25

WIP radio HIL testing

5412fb1

rebase

f7bd1d0

Harness test, reviews

896385f

JurajSadel force-pushed the wifi-hil branch from ed53161 to 896385f Compare April 20, 2026 12:36

bjoernQ reviewed Apr 27, 2026

View reviewed changes

MabezDev requested changes Apr 27, 2026

View reviewed changes

		@@ -0,0 +1,222 @@
		#[embedded_test::tests(default_timeout = 45, executor = esp_rtos::embassy::Executor::new())]

		@@ -0,0 +1,557 @@
		#[embedded_test::tests(default_timeout = 45, executor = esp_rtos::embassy::Executor::new())]

Conversation

JurajSadel commented Mar 17, 2026

Uh oh!

JurajSadel commented Mar 25, 2026

Uh oh!

github-actions Bot commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Mar 25, 2026

Uh oh!

github-actions Bot commented Mar 26, 2026

Uh oh!

github-actions Bot commented Mar 27, 2026

Uh oh!

github-actions Bot commented Mar 27, 2026

Uh oh!

MabezDev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JurajSadel commented Apr 2, 2026

Uh oh!

github-actions Bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MabezDev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Apr 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjoernQ commented Apr 27, 2026

Uh oh!

MabezDev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Mar 25, 2026 •

edited

Loading

github-actions Bot commented Apr 2, 2026 •

edited

Loading