Validating UDS across Linux sleep/wake on AMP SoCs like the STM32MP2

Here is a validation problem that, as far as we can tell, no diagnostics tool documents, and that every team shipping an asymmetric-multiprocessing SoC into a vehicle eventually hits.

---

The setup

Take an STM32MP2-class part: Cortex-A cores running Linux, a Cortex-M running Zephyr as a coprocessor. A common partitioning puts the vehicle-network and diagnostics duties on the M-core — it owns the CAN interface, runs the UDS server, holds the DTC store — while Linux does the heavy compute. The M-core domain can stay powered while the A-cores suspend; that is much of the point of the architecture.

Now walk through what your diagnostics stack must guarantee across a Linux suspend/resume cycle:

The UDS server keeps answering while Linux sleeps. A tester on the bus does not know or care that half the SoC is suspended — TesterPresent must still get its positive response within the session timing.

DTCs persist correctly across the window. Faults raised during sleep are recorded, and faults raised before suspend are still there after resume — including across the messy cases where resume involves a coprocessor firmware reload.

Shared resources handed back on resume do not corrupt diagnostic state. If Linux and the M-core coordinate over the CAN controller, NVM, or IPC mailboxes, the resume path is where that coordination breaks.

Session state behaves defensibly. An extended session opened before suspend either survives or times out cleanly per your P2/S3 configuration — not "sort of both."

Every one of these is testable. Almost nobody tests them, because the test requires orchestrating a power transition on the Linux side in the middle of a UDS sequence on the bus side — and the standard tools live entirely on the bus side.

---

How to test it today

You can build this with existing pieces. TestLab campaigns are YAML step sequences, so the pattern is: run the UDS steps from the host, and trigger the Linux power transition from a wrapper script between campaign runs.

#!/usr/bin/env bash
# sleep_wake_check.sh - orchestrate suspend around a campaign
testlab-run --config diagnostics_config.yaml \
  --campaign campaigns/pre_suspend.yaml --job seed_dtcs \
  --interface can0 --json reports/pre.json

ssh root@stm32mp2 systemctl suspend &
sleep 2   # let it go down

# ECU (M-core) should still answer while Linux sleeps:
testlab-run --config diagnostics_config.yaml \
  --campaign campaigns/during_suspend.yaml --job tester_present_alive \
  --interface can0 --json reports/during.json

ssh root@stm32mp2 true   # resume trigger per your board
testlab-run --config diagnostics_config.yaml \
  --campaign campaigns/post_resume.yaml --job dtc_persistence \
  --interface can0 --json reports/post.json

testlab compare --before reports/pre.json --after reports/post.json

The compare step at the end is the assertion that matters: the DTC set seeded before suspend is byte-identical after resume.

This works. It is also three campaign files and a shell script for what is conceptually one test scenario — and the power transition is not captured in the campaign's JSON record, so your report shows that a gap happened but not what happened in it.

---

The proposed answer: a power_state campaign action

What we would rather write — and what we are considering adding — is the power transition as a first-class campaign step:

# PROPOSED - this action does not exist yet
jobs:
  sleep_wake_dtc_persistence:
    steps:
      - action: session
        value:  extended
      - action: power_state
        trigger: suspend_linux     # signals the A-core via SSH/serial
      - action: delay
        ms: 5000
      - action: tester_present     # M-core must still respond
      - action: power_state
        trigger: resume_linux
      - action: read_dtc           # persistence survived?

One campaign, one JSON result, the suspend/resume events timestamped in line with the UDS steps, regression-diffable across firmware versions like any other TestLab run.

We have not built it. The honest reason: we gate features on demand, not on how satisfying they would be to implement, and we do not yet know how many teams have this problem versus how many will have it once STM32MP2-class parts ship in volume. The wrapper-script approach above is a real answer in the meantime.

---

Tell us if this is your problem

If you are validating diagnostics on an AMP SoC — STM32MP2 or otherwise — and the sleep/wake scenario is on your test plan (or worse, has already bitten you in the field), email us with a sketch of your topology. Enough signal and power_state moves from "proposed" to a version number. Silence is also signal; that is how a small, focused roadmap stays honest.