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

[Emil Lenngren]

Hi,

It seems like it is indeed a verified hardware bug or similar since the Errata 20 has now been updated. Previously it suggested as workaround to enable PLL but now it recommends to use CONSTLAT instead. Since this new workaround is more power consuming, I assume it must have been changed for a reason, namely due to the issue I experience.

From my experimentation it seems any workaround that involve keeping the MCU domain on is sufficient, including:

1. Use constant latency.
2. Keep TIMER00 running.
3. Keep the CPU running.
4. Keep the debugger running.

The different workarounds use different power consumption depending on which clocks are otherwise already requested by the system. When the radio is running, the TIMER00 approach seems to use ~20 µA less than the constlat approach, but ~100 µA less than constlat when the system is otherwise idling.

The errata suggests to keep constlat active only when the radio is active, but you recommend keeping constlat on the whole time HFXO is activated, any particular reason for that? Will it enhance radio performance? If not, that wastes a lot of energy since constlat then also needs to be on while the HFXO is ramping up, which takes hundreds of microseconds where in that case ~0.5 mA needs to be wasted during this period. I tested the two variants and turning on constlat as early as when HFXO is started results in a relatively big overall average increase of power consumption.

I also noticed that the workaround in the errata suggests to enable constlat also for RXEN, while the symptoms/conditions/consequences only indicate there is a problem with TX. I did some tests and indeed see that reception is affected as well (not correctly received packets occassionally) on my custom board, but not on the devkit. Using any of the four mentioned workarounds above, the problem goes away. Turning only PLL on is not sufficient. I suggest you to update the errata to indicate in symptoms/conditions/consequences that there are problems with reception as well.

[runsiv]

Thanks for the good feedback. 
I'm awating internal feedback. But my understanding is there will be some workaround implemented in the next release of the SDK. 
I will elaborate more when I hear back from the team. 

Regards

Runar