ESB and BLE concurrent issues on nRF54L series

[Esten]

Hello,

There are some issues I have found when I tried to achieve both BLE and ESB features concurrently on nRF54L chips, 
and some of them I have figured out how to fix, and some of them I can skip at this point but I need to know if it is correct paths or not.
Any suggestions please free to tell me.

NCS version: v3.0.0
Enviroment: nRF54L15 DKs / Ble peripheral role / ESB / Timeslot

Issue1: the conflicted TIMER10 when using ESB and Timeslot on nRF54L, this is a known issue from this ticket. According to the timeslot usage, the next normal request and releasing radio resources should be within a requested period and be eariler than the end of the timeslot, because of the issue, the extra hardware timer(like timer21) is used to replace the callback TIMER10 event. It worked but with flaws, only eraliest requests can be generated by the application right now.

Issue2: the conflicted RADIO handlers when using ESB and Timeslot on nRF54L, this issue is related to the principle  SDK source code.  From my opinions, the developers should never change any codes in NCS. I have to break this basic principle if I want the ESB module to work as I expected. The ESB uses radio interrupt handler function to operate generated radio events, the followings code snippet show the case:


  You have to explicitly delcare and call the radio_irq_handler function from the esb.c in the MPSL_TIMESLOT_SIGNAL_RADIO event(timeslot code) to make the esb radio interrupts work correctly.

Issue3: the advertising of ble does not work after esb_init is called in MPSL_TIMESLOT_SIGNAL_START event and esb_disable() is called in MPSL_TIMESLOT_SIGNAL_TIMER0(only for example, because the TIMER10 dose not work correctly, custom timer timeout handler instead).


Thanks in advanced.

[Hung Bui]

Hi Esten, 

You pretty much sum up the issues with concurrent ESB + BLE. I just want to clarify that now you have a prototype that works ? with ESB + BLE concurrent ? 

I assume you have read this thread ? RE: MPSL ESB and BLE timer problem. 
Following is the list of issue that my coworker who worked on this provided me: 

1. timer in radio domain is used by mpsl
2. dppi hardcoded, no ppib
3. no logic for adding more timers
4. gppi, which sets up ppib for you, cannot be used, as there is no concept of "nrfx_gppi group" in the scope of nRF54L.

As far as I know our R&D team is working on this and we are hoping to have a prototype by the next release of the SDK in a couple of month.

[Esten]

Hi Hung,
Yes, concurrent ESB + BLE can work perfectly in our nrf54L projects right now, the advertising / connection of BLE works when ESB receives or transmits at the same time. 

I have alreay read this thread and it can answer the issue1 above. About issue1, I don't have any more questions about it. Just like I said, another hardware timer can work at this point but with flaws.

About issue2 and  issue3, I want to hear the professional suggestions from Nordic, especially issue 3. I need to know if your team can make esb + ble work together without changing source codes like i have done.

[Hung Bui]

Hi Esten, 
I have sent your request internally. I will come back when I have a feedback from the team. 

[Esten]

Okay. Thank you for your information. I would be happy to hear any update .

[Hung Bui]

Hi Esten, 
I quote the feedback from our developer here: 

I think what the customer encountered while working with concurrent BLE + ESB is sort of expected. The ESB, due to it's fully asynchronous nature was never designed to operate contiguously with other protocols. I know that some customers make the ESB transmitter side work along BLE, and the issues they have, they fix with some workarounds like the customer mentioned here. We are planning to add support for concurrent BLE + ESB at some point, and will resolve these things properly then.

Regarding the ESB code not fitting well in the Timeslot API -it is like that because it was never designed to be used that way. The Radio event handling including the usage of shorts and PPIs is a bit complex in ESB to achieve the lowest possible latency, so there might be some impact on the operation in timeslot if the configs are not cleared well in some configurations e.g. CONFIG_NEVER_DISABLE_TX. I think the workaround they use with calling the ESB radio event handler from in the timeslot event is ok to use for now. Regarding the PPI issue - it needs additional analysis from our side.