About esb_ptx_ble & esb_prx_ble.

[Leo Mo]

Can I copy the ESB code from SDK v3.3.0-preview3 into SDK v2.9.0, and then get the functionality in esb_ptx_ble & esb_prx_ble?

 

Is there any way to achieve it quickly?

[Kenneth]

Hello,

Not sure I understand what problem you are trying to solve here, there should be ESB example projects for the nRF52840 in both the nRF Connect SDK releases you are referring to.

Can I copy the ESB code from SDK v3.3.0-preview3 into SDK v2.9.0, and then get the functionality in esb_ptx_ble & esb_prx_ble?

There may be some api changes, but for most part I would expect it should be pretty straight forward possible yes.

Kenneth

[Leo Mo]

Hello,

Using nRF Connect SDK v3.3.0, one device runs esb_ptx_ble and broadcasts 2 packets of data every 5-10ms, with 15 devices running esb_prx_ble，esb rx interval 7300ms，rx window 15ms， 30 seconds is a receiving cycle, and failure to receive a packet of data within the cycle is considered a failure; After running 15 devices for a few days, occasionally one device experiences dozens of consecutive cycles without receiving data. Why is that?

CONFIG_CONN_INTERVAL_MIN=990  //ms

CONFIG_CONN_INTERVAL_MAX=1010

CONFIG_CONN_LATENCY=6

Is it phase entanglement? Or is it another question? How can I solve it?

[Leo Mo]

Hi Edvin,

I encountered this bug again. It seems the logs are printed by the "ts_start_action" function and don't notify the outside world via the ESB_EVENT_TIMESLOT_FAILED event. Therefore, my application layer is unaware of the PPI error and doesn't reboot the device.

I'm using ESB + BLE central with several peripherals connected, which seems to make this bug more likely to be triggered.

Error log:

00> [09:52:57.440,979] <err> esb: gppi_channel_alloc failed with: -12
00> [09:52:57.440,979] <err> esb: Failed to initialize PPI

bridge-interconn-0812-1734.log

Best regards,

Leo

[Edvin]

Hello,

I see. It is an MPSL assert. According to our SoftDevice Controller team, this is caused by a user of a timeslot overstaying it's granted timeslot. The good news is that this is currently a known issue, and it was fixed in this pull request:

https://github.com/nrfconnect/sdk-nrf/pull/29998

Can you try to apply this pull request and see if the issue goes away?

Best regards,

Edvin

[Leo Mo]

Hi,

 Edvin I've already used this code:https://github.com/nrfconnect/sdk-nrf/pull/29998.

But I'm still encountering this issue. You can check my previous answers.

Best regards,

Leo

[Edvin]

Hello Leo,

Leo Mo said:

You can check my previous answers.

Did you say that you already included this PR? I am not sure I can see it. Can you point me to it?

Note that NCS v3.3.0 does not include this pull request.

Let us assume you recently ported your application to v3.3.0. Did you use the unmodified esb_tx_ble and esb_rx_ble to reproduce this issue? And you did includde PR 29998? Did you do anything else to your NCS SDK? Or is everything else left as is, so that if I built your application, I could reproduce what you are seeing using 2x nRF52840 DKs? If so, what should I look for? Does the log state when the issue occurs?

Best regards,

Edvin

[Leo Mo]

Hi

Yes, my code already includes this PR(subsys: esb: improve resource cleanup on init error paths by maje-emb · Pull Request #29998 · nrfconnect/sdk-nrf). You can check my previous replies, which include error logs and nRF52840DK code.

Best regards,

Leo