Radio TX doesn't work unless MCU domain is active during ramp-up

[Emil Lenngren]

I'm trying to send simple packets using the radio peripheral.

In my test scenario I have the following conditions:

1. The HFXO is started and is running the whole time. The PLL is also running all the time due to errata https://docs.nordicsemi.com/bundle/errata_nRF54L15_EngB/page/ERR/nRF54L15/EngineeringB/latest/anomaly_L15_20.html#anomaly_L15_20.
2. Using TIMER10 and DPPI, I transmit a radio packet every 100 ms.
3. CPU is otherwise sleeping using WFI.
4. Using a custom board having nRF54L15 chip with code N54L15 QFAABB 2435AB.
5. Internal capacitance of HFXO is configured correctly.
6. I use a nRF52833 devkit to receive packets and print every occurrence to the console.

Problem:

Depending on nRF54L15 board sample, the packet loss rate is ca 38%-80%. It's not that the CRC is wrong or packet is corrupted; it is simply not received at all in those cases. When testing multiple times on the same board, the packet loss ratio is pretty much constant over a few seconds.

However, if I replace the WFI by a busy-loop, keeping the CPU on, there is no packet loss anymore. Also if the debugger is connected, the issue does not occur. Alternatively, TIMER00 can be kept on instead.

I cannot reproduce the issue on the official devkit 0.8.1 having chip revision QFAABB 2433AA.

Current workaround:

Wake up the CPU and keep it active (in a busy-loop) while the radio is ramping up, or use DPPI to keep the TIMER00 on during the same time frame. Depending on board, I must in some cases extend the time the CPU or TIMER00 stays awake by some tens of microseconds.

Edit: for longer packets, the MCU domain needs to stay on for a longer time, otherwise I get CRC errors on the receiver side.

Question:

Is this a hardware bug missing an Errata or is it something wrong with the custom board?

Note that the SoftDevice Controller for BLE seems to work fine though on the same boards, is it already applying some workaround for this issue?

Note: This issue seems related to Errata 20 but with the difference that the packet cannot be received at all, as well as the workaround to keep PLL on is not sufficient.

[runsiv]

Hi

Since you can not replicate it on the DK, could you create a HW review case where you refer to this case? Just so that one of our HW engineers can take a look at your custom board? I will investigate a bit on our side to see if there is anything else that could be the issue

Regards

Runar

[Emil Lenngren]

Sure, how do I do that?

[Emil Lenngren]

With BLE SoftDevice Controller, packet loss rate is <1% (according to nRF sniffer).

When I reproduce the issue described, I'm not using any particular protrocol but just simply send raw radio packets using the radio peripheral. Tried radio modes Nrf_1Mbit, Nrf_2Mbit, Ble_1Mbit and Ble_2Mbit, all have the same issue.

[runsiv]

Thanks

You can try to add the constlat as used by the softdevice. You can see it enabled here https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/mpsl/init/mpsl_init.c#L525 As I understand it should reduce the failure rate significatly

Regards

Runar

[Emil Lenngren]

Per the documentation:

"In Constant Latency mode, the CPU wakeup latency and the PPI task response are constant and kept at a minimum. This is secured by forcing a set of basic resources to be turned on while in sleep mode. The cost of constant and predictable latency is increased power consumption."

Since constant latency also keeps the clocks on, that seems to be a similar workaround to using e.g. TIMER00 on. I just tested using constant latency and it seems to be a valid workaround as well.

However, the power consumption is higher than using TIMER00 instead. I measured the power consumpion of the whole system where everything is otherwise turned off, CPU sleeping in WFI, trying a combination of 64 vs 128 MHz clock configuration and turning on either constant latency or TIMER00, at 3.0V:

constlat 128 MHz: 570 µA
lowpwr TIMER00 128 MHz: 463 µA
constlat 64 MHz: 449 µA
lowpwr TIMER00 64 MHz: 354 µA

It seems like using the TIMER00 instead of constant latency for the workaround results in lower power consumption.

Since MPSL uses this workaround, does that mean there is indeed a known hardware issue that the clocks of MCU domain must be turned on in order for the radio peripheral to work properly (and that TASKS_PLLSTART is not enough)?

[runsiv]

Hi

I'm asking internally and will update when I hear back from them

Regards

Runar

[runsiv]

Hi and thank your for the patience, it seems like the case had fallen between different chairs when I went on vacation

The constlat work around is for enabling that case, so constlat is supposed to be stopped by triggering TASKS_LOWPWR so that the sleep current can be ~3-5uA.Conslat is only needed when the RADIO is active, so for the 100 ms between sending there is not need to have conslat active. I would recommend triggering CONSLAT=1  when starting the HFXO before sending and setting lowpower=1 when your turn of the HFXO. 

From what I can read it does not seem like I have a definitive answer to if it is a hardware bug or not. 

Regards

Runar