t4as

Research note · 2026-05-11

nRF54L15 PAwR Root-Cause Packet

Update, 1 October 2026: the cause was found. The board’s 32 kHz crystal runs about 175 ppm fast while the firmware declared 50 ppm, which narrows the PAwR receive windows below what this note describes. See Root cause: the 32 kHz clock. This note is kept as written in May.

Date: 2026-05-11

This is the short evidence packet for studying the nRF54L15 PAwR/PAST failure and turning it into a concise Nordic DevZone request. The detailed chronological log is in NRF54L15_PAST_DESYNC_TEST_LOG.md. Sniffer validation rules are in PAWR_SNIFFER_VALIDATION.md, and sniffer method/limits are explained in NRF54L15_SNIFFER_METHOD_AND_LIMITS.md. Production tag source safety is tracked in PRODUCTION_TAG_FIRMWARE_STATE.md. The stock Zephyr sample discriminator is in NRF54L15_MINIMAL_ZEPHYR_SAMPLE_RESULT.md. The adapted minimal reproducer is in NRF54L15_ADAPTED_MINIMAL_REPRODUCER_RESULT.md. A public technical overview is in NRF54L15_PUBLIC_PROJECT_OVERVIEW.md.

Current Diagnosis

The ESL failure is now narrowed to the PAwR synchronization/receive boundary after PAST, below the ESL application payload parser. A stock Zephyr PAwR/PAST sample pair on the same nRF54L15 AP and nRF52840 tag sustained responses, so this is not a global hardware or controller inability to do PAwR + PAST. A Zephyr-derived diagnostic sample moved toward the ESL profile reproduced the non-sustained response behavior, so the production ESL app is not required for the basic failure.

The strongest observed signature is:

  1. nRF54L15 AP GATT configuration succeeds.
  2. AP-side PAST API returns success.
  3. AP stages addressed response-producing PAwR payloads for ESL address 0x0001 / low address 0x01.
  4. Validated sniffer sees CRC-good AP SID 8, secondary extended advertising, and SyncInfo.
  5. Direct periodic-AA captures, using the SyncInfo access address and CRC init, see CRC-good periodic packets on air.
  6. The nRF52840 tag receives a PA sync callback and either receives exactly one valid PAwR event or no valid event, then reports recv_cb(..., buf=NULL) as #PAWR_RX_FAIL for every subsequent event.
  7. The tag silence watchdog tears down sync and the tag advertises again.

That means the issue is not explained by AP app failure to stage data, not by AP host API failure, not by lack of AP RF in the diagnostic baseline, and not by the ESL payload parser. The remaining uncertain boundary is whether the AP controller is transmitting a periodic train that later deviates from the SyncInfo timing/channel schedule, or whether the tag/controller loses receive tracking even though the AP train remains valid.

What Is Proven

  • Clean AP state matters. After tag chip erase, AP bonds and AP tag storage must both be cleared before interpreting results.
  • #SENSOR_PASTED and AP registry synced=1 are optimistic AP-side state. They are not proof of sustained tag PAwR sync.
  • The AP application stages and pushes addressed response-producing PAwR payloads after PAST.
  • The nRF54 AP emits CRC-good SyncInfo under the diagnostic AP baseline.
  • Forced 1M secondary does not fix the issue.
  • Slow extended advertising cadence does not fix the issue.
  • The attempted host channel-map override did not affect advertised SyncInfo in this SDC/NCS v2.8.0 setup.
  • The tag controller reports PAwR receive failures explicitly after CONFIG_BT_PER_ADV_SYNC_BUF_SIZE=64; this is not only an absence of application logs.
  • Stock Zephyr periodic_adv_rsp + periodic_sync_rsp samples on the same boards sustained PAwR responses after PAST, with 176 AP-side Response: subevent markers in a 150-second capture.
  • A Zephyr-derived minimal sample with SID 8, interval 1408, one subevent, ESL-like timing, and forced 1M reproduced the failure: 8 PAST/config cycles, 103 successful subevent-data sets, and only 1 AP-side response.
  • A Zephyr-derived long-interval / one-subevent / wider-slot comparison also failed: 5 PAST/config cycles, 85 successful subevent-data sets, and 0 AP-side responses.
  • A Zephyr-derived long-interval / one-subevent / wider-slot / single-sync comparison failed without repeated re-onboarding: 1 PAST/config cycle, 86 successful subevent-data sets, and 0 AP-side responses while the AP intentionally kept the first sync active.
  • A Zephyr-derived stock-interval / one-subevent / wider-slot comparison worked: 4 PAST/config cycles, 376 successful subevent-data sets, and 270 AP-side responses.
  • A Zephyr-derived long-interval / five-subevent / wider-slot comparison produced repeated responses: 15 PAST/config cycles, 170 successful subevent-data sets, and 12 AP-side responses.
  • A Zephyr-derived long-interval / one-subevent / wider-slot / 2M comparison failed: 5 PAST/config cycles, 69 successful subevent-data sets, and 0 AP-side responses.
  • A Zephyr-derived long-interval / two-subevent / wider-slot comparison partially recovered: 10 PAST/config cycles, 69 successful subevent-data sets, and 5 AP-side responses. All observed responses were for subevent 1; subevent 0 configurations were silent.
  • A Zephyr-derived long-interval / two-subevent / repeated-subevent-0 comparison failed: 10 PAST/config cycles, 68 successful subevent-data sets, and 0 AP-side responses. Subevent 0 slots 0 through 4 were configured twice each.
  • A Zephyr-derived long-interval / two-subevent / repeated-subevent-1 comparison worked: 8 PAST/config cycles, 68 successful subevent-data sets, and 8 AP-side responses. Every configured subevent 1 cycle produced a response.
  • A Zephyr-derived one-subevent interval sweep with wide slots found a sharp threshold: intervals 288, 296, 300, and 302 produced AP-side responses, while interval 303 and all tested larger values produced zero AP-side responses.
  • A full product-app release-candidate trial at interval 288, one subevent, clean AP/tag state, and production debug tag firmware still failed after PAST: security and PAST succeeded, but no real PAwR/NUS response was received.
  • A product-app trial at interval 288 with two subevents and default group 1 partially worked: the tag configured as ESL 0x0101, PAST succeeded, and the AP received real #PAWR_RSP, #NUS_STATUS, and #NUS_SENSORS responses on subevent 1; however sustained PAwR-only operation stopped later and get_name timed out. This is evidence for a partial workaround, not a release pass.
  • A clean repeat of the interval-288, two-subevent, default-group-1 product profile with tag RTT attached showed a sharper failure: PAST succeeded and the tag received sync info for two subevents, but the tag first received subevent 0 data (#PAWR_GROUP_MISMATCH:got=0x00,want=0x01), then repeatedly reported #PAWR_RX_FAIL:sub=1 and never produced AP-side #PAWR_RSP responses in that run.
  • The same clean RTT repeat exposed a potentially local tag-side timing hazard in the current recovery workaround. The tag’s deferred bt_le_per_adv_sync_subevent() retry was designed around the old long interval and targets roughly interval_ms - 300. With interval 288 (360 ms) this targets about 60 ms after the anchor, near the configured subevent-1 point (subevent_interval=48 -> 60 ms). The first retry then hit HCI opcode 0x2084 (LE Set Periodic Advertising Sync Subevent) with status 0x3a (BT_HCI_ERR_CONTROLLER_BUSY).
  • An AP-side bounded response retry experiment kept response-requesting PAwR payloads alive for repeated subevent-1 data requests (#PAWR_RETRY counted down from 63), but still produced no AP-side #PAWR_RSP or NUS response. The tag still received one subevent-0 wrong-group packet, then continuous #PAWR_RX_FAIL:sub=1.
  • A V3 isolated tag experiment requested the configured target group/subevent immediately in sync_cb; bt_le_per_adv_sync_subevent() returned success (#PAWR_SUB:sync_cb=0), but the first delivered packet was still subevent 0, followed by the same subevent-1 RX_FAILED stream. This clears “request target subevent immediately” as a sufficient local fix.

What Is Not Yet Proven With No Doubt

  • Whether the root is specifically nRF54L15 SoftDevice Controller periodic advertiser scheduling after PAST.
  • Whether the root is nRF52840 receiver/controller PAwR sync tracking after PAST.
  • Which exact small-subevent condition turns the working PAwR/PAST path into the non-sustained response/RX_FAILED failure: a controller edge case around the first/only response-capable subevent or subevent phase, the interval threshold around 303/304, ACL teardown interaction in the full product app, or a schedule/tracking difference that the current sniffer does not yet follow event by event.

The current evidence strongly points below the ESL payload parser. The next escalation should be framed around PAwR + PAST under long-interval / one-subevent timing rather than a generic PAwR/PAST failure.

Controlled Sniffer Validation

  • Doc: PAWR_SNIFFER_VALIDATION.md
  • Controlled nRF54 signal run: ../logs/sniffer_validation/20260511_125546Z/sniffer_summary.json

Why it matters: proves the racoon sniffer can catch CRC-good SID 8, secondary packets, SyncInfo, and service UUID evidence from a known-good nRF54 source.

Real AP 2M RF Gate And One-RX Failure

  • Detailed section: NRF54L15_PAST_DESYNC_TEST_LOG.md
  • Run: 20260511_145757Z
  • Preflight sniffer: ../logs/correlated_pawr/20260511_145757Z/preflight/sniffer_summary.json
  • Main sniffer: ../logs/correlated_pawr/20260511_145757Z/sniffer/sniffer_summary.json
  • AP log: ../logs/correlated_pawr/20260511_145757Z/ap_diag.log
  • Tag RTT: ../logs/correlated_pawr/20260511_145757Z/tag_rtt.log

Key fact: AP RF/SyncInfo is proven before and during the full run. The tag gets #SYNC:1 and exactly one PAwR event, then no sustained receive.

Forced 1M RF Gate And PAST Failure Variant

  • Run: 20260511_150808Z
  • Preflight sniffer: ../logs/correlated_pawr/20260511_150808Z/preflight/sniffer_summary.json
  • Main sniffer: ../logs/correlated_pawr/20260511_150808Z/sniffer/sniffer_summary.json
  • AP log: ../logs/correlated_pawr/20260511_150808Z/ap_diag.log
  • Tag RTT: ../logs/correlated_pawr/20260511_150808Z/tag_rtt.log

Key fact: AP emits CRC-good SID 8, LE 1M secondary, and SyncInfo. Forced 1M does not make the tag sustain PAwR.

RX_FAILED And Direct Periodic-AA Proof

  • Run: 20260511_172925Z
  • AP log: ../logs/correlated_pawr/20260511_172925Z/ap_diag.log
  • Tag RTT: ../logs/correlated_pawr/20260511_172925Z/tag_rtt.log
  • Main sniffer summary: ../logs/correlated_pawr/20260511_172925Z/sniffer/sniffer_summary.json
  • Direct periodic-AA summary: ../logs/correlated_pawr/20260511_172925Z/direct_periodic_aa/sniffer_summary.json
  • Direct periodic-AA raw JSONL: ../logs/correlated_pawr/20260511_172925Z/direct_periodic_aa/sniffer.jsonl

Key facts:

  • SyncInfo-derived AA=0x647D6EBE, CRC=0xD40629.
  • Direct periodic-AA capture found 6 CRC-good periodic packets on that AA.
  • Tag received one valid PAwR event at event 71, then #PAWR_RX_FAIL for events 72 through 96.

Slow Cadence Negative Result

  • Run: 20260511_181151Z
  • AP log: ../logs/correlated_pawr/20260511_181151Z/ap_diag.log
  • Tag RTT: ../logs/correlated_pawr/20260511_181151Z/tag_rtt.log
  • Main sniffer summary: ../logs/correlated_pawr/20260511_181151Z/sniffer/sniffer_summary.json
  • Direct periodic-AA summary: ../logs/correlated_pawr/20260511_181151Z/direct_periodic_aa/sniffer_summary.json
  • Direct periodic-AA raw JSONL: ../logs/correlated_pawr/20260511_181151Z/direct_periodic_aa/sniffer.jsonl

Key facts:

  • SyncInfo-derived AA=0xD9522E15, CRC=0x10888A.
  • Direct periodic-AA capture found 7 CRC-good periodic packets on that AA.
  • Tag received one valid PAwR event at event 90, then #PAWR_RX_FAIL for events 91 through 115.

Channel-Map Override Negative Result

  • Run: 20260511_184712Z
  • AP log: ../logs/correlated_pawr/20260511_184712Z/ap_diag.log
  • Tag RTT: ../logs/correlated_pawr/20260511_184712Z/tag_rtt.log
  • Preflight sniffer summary: ../logs/correlated_pawr/20260511_184712Z/preflight/sniffer_summary.json
  • Main sniffer summary: ../logs/correlated_pawr/20260511_184712Z/sniffer/sniffer_summary.json

Key facts:

  • Generated config had single-channel override enabled for the test.
  • Every captured SyncInfo still advertised full channel map ffffffff1f.
  • Tag got sync but no valid PAwR payload, only RX_FAILED events.

Stock Zephyr Sample Positive Control

Key facts:

  • AP sample: ~/ncs/v2.8.0_clear/zephyr/samples/bluetooth/periodic_adv_rsp on nrf54l15_connectkit/nrf54l15/cpuapp.
  • Tag sample: ~/ncs/v2.8.0_clear/zephyr/samples/bluetooth/periodic_sync_rsp on adafruit_itsybitsy/nrf52840.
  • Same NCS v2.8.0 SoftDevice Controller family.
  • 150-second capture showed PAST sent, PAwR config written, and 176 Response: subevent markers.
  • After the test, the production tag image and nRF54 ESL diagnostic AP image were restored.

Interpretation: PAwR + PAST is viable on this hardware/controller combination under the stock sample profile. The remaining reproducer work should mutate the stock sample toward the ESL profile one parameter at a time.

Adapted Minimal Reproducer

  • Doc: NRF54L15_ADAPTED_MINIMAL_REPRODUCER_RESULT.md
  • ESL-profile timing capture: ../logs/minimal_pawr_past/20260511_esl_profile_timing/ttyACM0.log
  • Long-interval / wide-slot capture: ../logs/minimal_pawr_past/20260511_long_interval_wide_slots_real/ttyACM0.log
  • Diagnostic AP source: ../diagnostics/pawr_esl_profile_adv/src/main.c
  • Diagnostic receiver source: ../diagnostics/pawr_esl_profile_sync/src/main.c

Key facts:

  • ESL-profile timing run printed sid=8,interval=1408,num_subevents=1,subevent_interval=11,rsp_delay=8,rsp_spacing=3,rsp_slots=8,phy=1M.
  • That run produced 8 successful PAST/config cycles, 103 successful AP subevent-data sets, and only 1 response.
  • Long-interval / wide-slot comparison printed sid=8,interval=1408,num_subevents=1,subevent_interval=48,rsp_delay=5,rsp_spacing=80,rsp_slots=5,phy=1M.
  • That comparison produced 5 successful PAST/config cycles, 85 successful AP subevent-data sets, and 0 responses.
  • Long-interval / one-subevent / single-sync comparison used the same AP profile, configured subevent 0 slot 0 once, kept the sync active, and produced 1 successful PAST/config cycle, 86 successful AP subevent-data sets, and 0 responses.
  • Stock-interval / one-subevent comparison printed sid=8,interval=255,num_subevents=1,subevent_interval=48,rsp_delay=5,rsp_spacing=80,rsp_slots=5,phy=1M.
  • That comparison produced 4 successful PAST/config cycles, 376 successful AP subevent-data sets, and 270 responses.
  • Long-interval / five-subevent comparison printed sid=8,interval=1408,num_subevents=5,subevent_interval=48,rsp_delay=5,rsp_spacing=80,rsp_slots=5,phy=1M.
  • That comparison produced 15 successful PAST/config cycles, 170 successful AP subevent-data sets, and 12 responses.
  • Long-interval / one-subevent / 2M comparison printed sid=8,interval=1408,num_subevents=1,subevent_interval=48,rsp_delay=5,rsp_spacing=80,rsp_slots=5,phy=2M.
  • That comparison produced 5 successful PAST/config cycles, 69 successful AP subevent-data sets, and 0 responses.
  • Long-interval / two-subevent comparison printed sid=8,interval=1408,num_subevents=2,subevent_interval=48,rsp_delay=5,rsp_spacing=80,rsp_slots=5,phy=1M.
  • That comparison produced 10 successful PAST/config cycles, 69 successful AP subevent-data sets, and 5 responses. All observed responses were for subevent 1; subevent 0 slots 0 through 4 were configured but produced no AP-side responses in this capture.
  • Long-interval / two-subevent / repeated-subevent-0 comparison used the same AP profile, configured subevent 0 slots 0 through 4 twice each, and produced 10 successful PAST/config cycles, 68 successful AP subevent-data sets, and 0 responses.
  • Long-interval / two-subevent / repeated-subevent-1 comparison used the same AP profile, configured subevent 1 on each PAST/config cycle, and produced 8 successful PAST/config cycles, 68 successful AP subevent-data sets, and 8 responses.
  • One-subevent interval sweep with wide slots produced responses at intervals 288, 296, 300, and 302, then zero responses at 303, 303 retry, 304, 320, 384, 512, and 768.

Product Release-Candidate Trial

  • Doc: NRF54L15_STABLE_288_RELEASE_CANDIDATE.md
  • One-subevent product test: ../logs/stable_288_profile/20260512_release_candidate/host_console_test_clean_state.log
  • Two-subevent group-1 product test: ../logs/stable_288_profile/20260512_release_candidate/host_console_test_group1.log

Key facts:

  • One-subevent interval 288 is not enough for the full product app: PAST succeeds, but no #PAWR_RSP or NUS response appears.
  • Two-subevent interval 288 with CONFIG_ESL_CLIENT_DEFAULT_GROUP_ID=1 assigns the tag to ESL 0x0101 and produces real subevent 1 PAwR/NUS responses for status and sensors.
  • The group-1 run is still not release-stable: after ACL disconnect, later PAwR-only NUS/polling stopped and get_name timed out.

Clean Group-1 RTT Repeat

  • Run directory: ../logs/deep_esl_group1_acl/20260512_rtt01
  • AP retry log: ../logs/deep_esl_group1_acl/20260512_rtt01/ap_focused_nus_retry_clean.log
  • Tag RTT: ../logs/deep_esl_group1_acl/20260512_rtt01/tag_rtt.log

Key facts:

  • Security, MTU exchange, ESL configuration, and PAST succeeded.
  • AP staged response-producing subevent-1 NUS commands (op=0x1f, addr=0x01, rsp=1) but received no #PAWR_RSP in this clean repeat.
  • Tag sync callback reported int=288, num=2, sub_int=48, rsd=5, rss=80, and #PAWR_SUB:sync_cb=0.
  • The tag then received one subevent-0 packet and rejected it as group mismatch: #PAWR_RX:378274 sub=0 ev=1431, #PAWR_GROUP_MISMATCH:ev=1431,got=0x00,want=0x01.
  • The tag immediately hit opcode 0x2084 status 0x3a while trying to refresh the subevent filter, then reported continuous #PAWR_RX_FAIL:sub=1,rssi=127,state=3 until the PA-silence watchdog recovered.

Interpretation: this repeat no longer looks like a get_name payload-length failure. It points at the transition from the initial subevent filter setup to stable group/subevent-1 reception. The current tag recovery workaround is also suspect under the short interval-288 profile because its retry timing was written for long intervals and can collide with the subevent-1 window.

AP Retry And Target-Subevent Negative Split

  • Run directory: ../logs/pawr_resub_exp/20260512_exp03_ap_retry
  • AP retry host log: ../logs/pawr_resub_exp/20260512_exp03_ap_retry/host_console_test.log
  • AP retry tag RTT: ../logs/pawr_resub_exp/20260512_exp03_ap_retry/tag_rtt.log
  • V3 target-sub host log: ../logs/pawr_resub_exp/20260512_exp03_ap_retry/host_console_test_v3_target_sub.log
  • V3 target-sub tag RTT: ../logs/pawr_resub_exp/20260512_exp03_ap_retry/tag_rtt_v3_target_sub.log

Key facts:

  • AP bounded retry is default-off globally and enabled only in the nRF54L15 board config for this experiment with CONFIG_ESL_PAWR_RESPONSE_RETRY_COUNT=64.
  • Commissioning, ESL configuration, and PAST succeeded in both runs; AP registered the tag as ESL 0x0101.
  • The AP repeatedly re-pushed the response-requesting subevent-1 NUS status payload: #PAWR_RETRY:sub=1,left=63,op=0x1f,addr=0x01 down through later retry counts.
  • No #PAWR_RSP, #NUS_STATUS, #NUS_SENSORS, or #SENSOR_NAME appeared; the host test timed out waiting for esl_c nus status 0x0101.
  • In the AP-retry run, tag RTT showed #SYNC_CB:...int=288,num=2,sub_int=48..., then #PAWR_RX ... sub=0, #PAWR_GROUP_MISMATCH:ignore_first, and repeated #PAWR_RX_FAIL:...sub=1.
  • In the V3 target-sub run, the isolated tag requested target subevent 1 from sync_cb and logged #PAWR_SUB:sync_cb=0, but the first delivered packet was still #PAWR_RX ... sub=0, followed by the same repeated #PAWR_RX_FAIL:...sub=1 stream.

Interpretation: AP one-shot response-payload lifetime is not sufficient to explain the failure, because repeated AP pushes do not help when the tag never receives subevent 1. The immediate target-subevent request is also not sufficient; the controller still delivers subevent 0 first and then reports RX_FAILED on subevent 1. This strengthens the case for a lower controller/schedule/subevent-phase boundary rather than only AP command lifetime or a local delayed-resubscribe bug.

Interpretation: the failure can be reproduced without the production ESL app, but the product app confirms the same boundary matters in a real gateway. Widening response-slot timing did not recover the long-interval one-subevent sample, one-subevent PAwR works below the interval cliff, long interval 1408 produces responses when stock-style 5 subevents are used, switching the failing profile back to 2M does not help, repeated re-onboarding is not required, and a two-subevent long-interval profile recovers on subevent 1 while subevent 0 remains silent. The strongest current suspect is a controller/scheduling boundary around subevent index/phase and interval in a PAwR train after PAST.

Most Likely Failing Boundary

Current best phrasing:

After PAST, the nRF52840 tag receives PAwR synchronization information from the nRF54L15 AP, but sustained PAwR receive fails at the controller periodic receive layer. AP-side host/controller APIs accept PAST and PAwR subevent data, and sniffer evidence proves the AP emits SyncInfo and CRC-good periodic-AA packets. The tag host callback receives buf=NULL RX_FAILED reports for subsequent events, before the ESL parser can see payloads.

Do not phrase the DevZone request as “the app does not get a response”. Phrase it as “PAwR sync transfer succeeds, AP transmits periodic packets, but the receiver reports RX_FAILED after one event”.

Next Discriminator

Use the isolated diagnostic samples, the product release-candidate logs, the clean group-1 RTT repeat, and the AP-retry/V3 negative split together. The unmodified stock samples sustained responses, the adapted diagnostics show both a subevent-index split and an interval threshold near 303/304, and the product app confirms that moving to group/subevent 1 can give real responses but not sustained long-term operation. The latest isolated experiments clear AP one-shot command lifetime and immediate target-subevent subscription as sufficient fixes. The next split should change one remaining group at a time:

  • Repeat the interval threshold around 302/303/304 on a newer controller stack if practical.
  • Test an AP profile that deliberately puts the first production tag back into group/subevent 0 under otherwise identical interval-288 conditions, to separate group-id mapping from first-delivered-subevent behavior.
  • Test one-subevent versus two-subevent product profiles with the same retry instrumentation and tag RTT, using clean AP reset after remove_all_tags so stale in-memory registry state cannot leak between runs.
  • Repeat the interval-288 group-1 product run on a newer controller stack if practical.
  • Repeat the minimal subevent-index split on a newer controller stack if practical.

Outcome interpretation:

  • Since long interval with stock 5 subevents works and stock interval with one subevent works, focus on the long-interval + one-subevent combination.
  • Since a no-re-onboarding run fails the same way, repeated PAST/onboarding is cleared as the required trigger.
  • Since two subevents recover on repeated subevent 1, and repeated subevent 0 remains silent, follow up on subevent index/phase rather than treating the result as a simple pass.
  • Since the product group-1 trial gets initial responses but later repeats can fail before any subevent-1 payload reaches the tag, do not present the current nRF54L15 gateway as long-term release-stable yet.
  • Since the 2M run fails the same way, forced 1M is cleared.
  • Since AP retry keeps the payload alive but does not produce responses, do not treat PAwR command lifetime as the primary remaining root cause.

A second, more precise sniffer discriminator would be a SyncInfo follower that predicts event channels/times from event_counter, interval, channel_map, AA, and CRC. That would answer whether the nRF54 AP periodic train follows the BLE schedule after the first received event.

Draft DevZone Request Core

Title idea:

nRF54L15 PAwR advertiser + PAST: nRF52840 receiver syncs then reports RX_FAILED for every subsequent PAwR event despite CRC-good AP periodic packets

Core text:

We are debugging an ESL PAwR/PAST setup on NCS v2.8.0. The AP is a Makerdiary nRF54L15 Connect Kit using SoftDevice Controller. The tag is nRF52840. A stock Zephyr periodic_adv_rsp / periodic_sync_rsp pair on the same boards sustains PAwR responses after PAST, but a Zephyr-derived diagnostic sample fails when moved to the ESL-like long-interval / one-subevent profile. PAST transfer returns success and the tag receives a PA sync callback with SID 8, interval 1408, one subevent, subevent interval 11, response-slot delay 8, spacing 3, and service UUID 0x1857. The AP then stages response-requesting addressed PAwR payloads and bt_le_per_adv_set_subevent_data() returns success.

Further diagnostic splits found that one-subevent wide-slot profiles respond below an interval cliff (288, 296, 300, 302) and stop responding at 303 and above in this setup. Long-interval two-subevent diagnostics repeatedly respond on subevent 1 while subevent 0 remains silent. In the full ESL app, an interval 288 group-1 profile produces initial real PAwR/NUS responses, but sustained PAwR-only operation still stops after ACL disconnect.

Using a validated external sniffer, we can prove the nRF54 AP emits CRC-good SID 8, secondary extended advertising, SyncInfo, and direct CRC-good periodic packets on the SyncInfo-derived access address/CRC init. However, the nRF52840 tag receives either exactly one PAwR event and then recv_cb(..., buf=NULL) RX_FAILED on every subsequent event, or receives no valid PAwR payload and only RX_FAILED. The tag then times out and advertises again.

We would like help determining whether this is a known SDC/Zephyr controller limitation or bug around PAwR advertiser scheduling, PAST, or periodic receive tracking, and what controller-level diagnostics can prove whether the AP periodic train remains schedule-correct after PAST.

Attach or link:

  • This packet.
  • The detailed chronological log.
  • The sniffer validation doc.
  • 20260511_172925Z AP/tag/sniffer/direct-AA artifacts.
  • 20260511_181151Z slow-cadence/direct-AA artifacts.
  • 20260511_184712Z channel-map override artifacts.
  • Stock Zephyr sample positive-control artifact: logs/minimal_pawr_past/20260511_stock_samples/ttyACM0.log.
  • Adapted minimal reproducer artifacts: logs/minimal_pawr_past/20260511_esl_profile_timing/ttyACM0.log and logs/minimal_pawr_past/20260511_long_interval_wide_slots_real/ttyACM0.log.
  • Single-sync long-interval / one-subevent negative split: logs/minimal_pawr_past/20260511_long_interval_one_subevent_single_sync_retry/ttyACM0.log.
  • Stock-interval / one-subevent positive split: logs/minimal_pawr_past/20260511_stock_interval_one_subevent/ttyACM0.log.
  • Long-interval / five-subevent positive split: logs/minimal_pawr_past/20260511_long_interval_5_subevents/ttyACM0.log.
  • Long-interval / one-subevent / 2M negative split: logs/minimal_pawr_past/20260511_long_interval_one_subevent_2m/ttyACM0.log.
  • Long-interval / two-subevent partial split: logs/minimal_pawr_past/20260511_long_interval_2_subevents/ttyACM0.log.
  • Long-interval / two-subevent / repeated-subevent-0 negative split: logs/minimal_pawr_past/20260511_long_interval_2_subevents_subevent0/ttyACM0.log.
  • Long-interval / two-subevent / repeated-subevent-1 positive split: logs/minimal_pawr_past/20260511_long_interval_2_subevents_subevent1/ttyACM0.log.
  • Interval sweep logs: logs/minimal_pawr_past/20260511_interval_0288_one_subevent/ through logs/minimal_pawr_past/20260511_interval_0768_one_subevent/.
  • Product release-candidate doc and logs: docs/NRF54L15_STABLE_288_RELEASE_CANDIDATE.md, logs/stable_288_profile/20260512_release_candidate/host_console_test_clean_state.log, and logs/stable_288_profile/20260512_release_candidate/host_console_test_group1.log.
  • AP retry and V3 target-subevent negative split: logs/pawr_resub_exp/20260512_exp03_ap_retry/host_console_test.log, logs/pawr_resub_exp/20260512_exp03_ap_retry/tag_rtt.log, logs/pawr_resub_exp/20260512_exp03_ap_retry/host_console_test_v3_target_sub.log, and logs/pawr_resub_exp/20260512_exp03_ap_retry/tag_rtt_v3_target_sub.log.