nRF54L15-DK: Periodic "rx failed error" (1, 2, 9) in 802154_phy_test example

[yong0]

Hello, I am currently experiencing an issue with the 802154_phy_test example on the nRF54L15-DK board, and I would appreciate your technical support.

[ Environment ]

- Hardware: nRF54L15-DK

- SDK: nRF Connect SDK v3.3.0

- Toolchain: nRF Connect SDK Toolchain v3.3.0

- Application: 802154_phy_test example (Default configuration)

[ Symptom / Problem ]

When running the example without modification, the following error messages are continuously printed on the console log:

- "rx failed error 1!" - "rx failed error 2!" - "rx failed error 9!"

[ Additional Context ]

- The errors appear randomly without any specific pattern or constant period.

- To rule out any RF interference or multi-path fading from the surrounding environment, we conducted a test in the middle of a wide-open soccer field. However, the exact same errors occurred.

- We have not modified the core PHY test source code. Could you please provide insight into what causes these specific error codes (1, 2, and 9) during RX operations? Any suggestions on how to debug or resolve this issue would be highly appreciated. Thank you.

[Simonr]

Hi

What is the transmitter in this setup? The error messages can be read from nrf_802154_rx_error_t in nrf_802154_types.h.

• Error 1 points to a malformed frame being received.
• Error 2 points to a frame with an invalid checksum being received
• Error 9 points to a frame with invalid length being received.

So I think that the transmitted packets here aren't valid in one way or another.

Best regards,

Simon

[yong0]

Hello Simon,

Thank you for your response.

To clarify, there is no external transmitter in my setup. The nRF54L15-DK is generating these error messages on its own while running the 802154_phy_test example.

As I mentioned previously, I have taken the following steps to troubleshoot:

• Environment test: To rule out any external RF interference or noise, I conducted the test in the middle of a wide-open soccer field, but the issue persisted exactly the same.

• Error pattern: The error codes (1, 2, and 9) appear randomly without any specific period or pattern.

Since there is no transmitter sending packets, it seems the hardware is generating these "rx failed" events internally.

[Simonr]

Hi

Do the errors happen as soon as you start the sample project, or once you start an RX test on the sample with rstart?

If you don't have an external transmitter, and the RX is running, it will just scan for packets, and if you're in a "generic" office environment it will likely pick up random packets on the band from various devices, and these would likely be invalid in some way, which would explain the error messages I think.

Best regards,

Simon

[yong0]

Hi Simon,

The errors are occurring immediately after the initial boot, prior to any command entry, including the 'rstart' command.

As you can see from the attached image, the error messages appear right after powering on the device, without any user intervention.

Additionally, my nRF54L15 DK version is PCA10156 1.0.0 2025.48.

Best regards,

Jiyong

[Simonr]

Hi

Okay, so I think I've found what's wrong here, and it seems to be a bug in the sample project. There is an issue with the way return values are passed back form SWI calls. As a pointer where the value will be written is pushed to the queue along with the parameters. Sometimes the value is read before it is written, resulting in issues like this. 

Our developers are working on a proper fix for this, but as a workaround for now, it should be okay to add a few "nops" after unmasking interrupts in the req_exit() function:

static void req_exit(void)
{
    nrf_802154_queue_push_commit(&m_requests_queue);

    nrf_egu_task_trigger(NRF_802154_EGU_INSTANCE, REQ_TASK);

    nrf_802154_mcu_critical_exit(m_mcu_cs);

    for (int i = 0; i < 4; i++)
        __asm__ volatile("nop");
}

Best regards,

Simon