================================================================================
nRF70 Wi-Fi TX-Stall Investigation - Follow-up Capture
Matter Light Bulb over Wi-Fi (nRF54LM20 DK + nRF7002 EB II), NCS v3.3.4
Captured: 2026-10-12
================================================================================

PURPOSE
-------
Per the Wi-Fi team's request, firmware was rebuilt with the nrf70-driver-debug
snippet (NOT the verbose variant), the TX-stall was reproduced, and the
nrf70 util tx_stats / rpu_stats commands were captured while the device was in
the failed state.

BUILD UNDER TEST
----------------
Sample:   nrf/samples/matter/light_bulb (NCS v3.3.4)
Board:    nrf54lm20dk/nrf54lm20a/cpuapp
Shield:   nrf7002eb2
Snippet:  nrf70-driver-debug          <-- as requested (not verbose-debug)
Key opts: SB_CONFIG_WIFI_NRF70=y, CONFIG_CHIP_WIFI=y, CONFIG_NRF_WIFI_LOW_POWER=n
nRF70 FW: v1.2.14.8
Watchdog: not enabled in this build (device does NOT self-reset on stall)

REPRODUCTION
------------
1. Commissioned the light bulb onto Wi-Fi via a Matter controller (Apple Home).
2. Exercised the device until it stopped responding in Apple Home (TX stall).
3. With the device confirmed stuck (unresponsive at the controller, no unicast
   to air), ran the requested command sequence over the Zephyr shell:
     - nrf70 util tx_stats 0     x5
     - nrf70 util rpu_stats all  x5
   The serial port was opened without toggling DTR/RTS so the capture itself
   could not reset the board; the device remained in the failed state for the
   entire capture (no reboot - confirmed, no "Booting" banner in the window).

KEY OBSERVATION (rpu_stats, 5 runs over ~30 s while stuck)
----------------------------------------------------------
  run | tx_done_success_pkts_to_host | tx_dones_from_lmac | total_cmds_to_lmac | total_rx_pkts_from_lmac
   1  |            229               |        233         |       4495         |        5578
   2  |            230               |        234         |       4560         |        5647
   3  |            231               |        235         |       4625         |        5714
   4  |            231               |        235         |       4688         |        5787
   5  |            232               |        236         |       4751         |        5876
  ----|------------------------------|--------------------|--------------------|------------------------
 delta |             +3               |         +3         |       +256         |         +298

Interpretation:
  - RX path is fully alive: total_rx_pkts_from_lmac advances by ~298 packets.
  - Host->LMAC command path is active: total_cmds_to_lmac advances by ~256.
  - TX completions are effectively frozen: tx_done_success_pkts_to_host and
    tx_dones_from_lmac advance by only +3 across the whole window.
  => Frames are still being submitted to the RPU, but TX-done completions are
     not coming back. TX is dead-ended at the RPU/LMAC while RX and the command
     path remain healthy. This matches the "TX path stuck at the driver level,
     unicast not reaching air" hypothesis.

tx_stats 0 (all 5 runs): every access category reports
  Outstanding tokens: 0, pending_q_len: 0  (no backlog visible at the host
  shim; the stall is below this layer).

MATTER-LAYER SYMPTOMS DURING THE STALL (from the driver-debug log)
------------------------------------------------------------------
  - [DMG] Time out! failed to receive status response ... Subscription torn down
  - [EM]  Msg Retransmission ... failure (max retries:4)
  - [SC]  CASESession timed out while waiting for a response from peer
  - [DMG] Failed to establish CASE for subscription-resumption with error '32'
  - [DIS] Timeout waiting for mDNS resolution
  Consistent with outbound unicast not being delivered.

RECOVERY
--------
No watchdog is enabled in this build, so the device does NOT auto-recover; it
stays stuck until a manual reset / power-cycle.

ATTACHED LOGS
-------------
  tx_stall_capture2.log  - PRIMARY. Full driver-debug log through the stall plus
                           the 5x tx_stats + 5x rpu_stats captured while stuck,
                           with no reboot during the capture window.
  tx_stall_capture.log   - First attempt (context). Contains tx_stats runs 1-4
                           from the stuck state; the board reset partway through
                           (serial-port close toggled the reset line), so the
                           rpu_stats runs in that file are post-reboot and should
                           be disregarded. Included only for completeness.
================================================================================
