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?

[runsiv]

Just create a new private case where you upload the following:

Schematics

Gerber files

Please do include the values on the schematic 

Regards

Runar

[Emil Lenngren]

Case ID: 337882

[runsiv]

Thanks Emil, I see that the case was assign to our team

Just to clarify something, when you say 

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?

Is the package loss for BLE less then the 35-80%? If so what protocol do you use to transfer data?

Regards

Runar

[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