You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test(hw): add RX data-capture smoke test to every hw test
``assert_jesd_links_data`` verifies the JESD204 link reports
``Link status: DATA``, but that only says the transport reached the
data state at link-up — drivers can probe cleanly, IIO devices can
appear, the link can show DATA, and yet no samples actually arrive
through the AXI-DMA path. Silent "drivers look OK, buffer comes
back all-zero / constant" is the single most common CI failure
mode and the existing assertions miss it completely.
Add ``assert_rx_capture_valid(device, n_samples=2**12, min_std=1.0,
context="")`` to ``test/hw/hw_helpers.py``. Takes any pyadi-iio
RX-capable instance, configures the buffer size, calls ``rx()``,
and asserts:
- Every channel delivered exactly ``n_samples``.
- At least one channel is not all-zero (DMA actually transferred
bytes).
- At least one channel's ``|std|`` is ``>= min_std`` LSBs (samples
vary; a latched converter or a disconnected FIFO does not clear
this even at one LSB).
Wire it into every hw test that already has IIO verification,
using the chip-appropriate pyadi-iio class:
- ``test_ad9081_zcu102_xsa_hw.py`` → ``adi.ad9081``
- ``test_ad9081_zcu102_system_hw.py`` → ``adi.ad9081``
- ``test_adrv9009_zcu102_hw.py`` → ``adi.adrv9009``
- ``test_adrv9371_zc706_hw.py`` → ``adi.ad9371``
- ``test_fmcdaq3_vcu118_hw.py`` → ``adi.daq3``
Each site pulls the IP address out of the existing
``open_iio_context(shell)`` return tuple so no extra boot traffic
is needed. The capture happens after ``assert_jesd_links_data``
so a link-down regression still surfaces on the clearer JESD check
rather than an opaque "samples look wrong" failure.
0 commit comments