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?

[Edvin]

Hello Leo,

Are you able to replicate this issue on 2x nRF52840 DKs? If so, is it possible to upload an application that can reproduce the issue without any external components attached?

Best regards,

Edvin

[Leo Mo]

Hi Edvin,

I tried to reproduce the issue using the nRF52840 DK, but haven't encountered it yet. As mentioned earlier, it might take 5-10 days for the problem to appear.

Best regards,

Leo

[Edvin]

I understand. Let me know if you are able to. 

I canæt see that you have uploaded any code (other than snippets). But looking at NCS v3.3.0, these lines:

[00:08:53.592,987] <err> esb: Failed to initialize PPI
[00:08:54.115,539] <err> esb: gppi_channel_alloc failed with: -12

Seems to come from:

v3.3.0\nrf\subsys\esb\esb.c:

static mpsl_timeslot_signal_return_param_t *ts_start_action(void)
{
	nrf_radio_mode_set(NRF_RADIO, (nrf_radio_mode_t)esb_cfg.bitrate);
	update_radio_crc();
	update_rf_payload_format(esb_cfg.payload_length);

	update_radio_addresses(ADDR_UPDATE_MASK_BASE0 | ADDR_UPDATE_MASK_BASE1 |
			       ADDR_UPDATE_MASK_PREFIX);

	nrf_radio_fast_ramp_up_enable_set(NRF_RADIO, esb_cfg.use_fast_ramp_up);

#if defined(CONFIG_ESB_FAST_CHANNEL_SWITCHING)
	nrf_radio_int_enable(NRF_RADIO, NRF_RADIO_INT_RXREADY_MASK);
#endif /* defined(CONFIG_ESB_FAST_CHANNEL_SWITCHING) */

	apply_radio_init_workarounds();

	int err = esb_ppi_init();

	if (err) {
		LOG_ERR("Failed to initialize PPI");

and v3.3.0\nrf\subsys\esb\esb_ppi.c:

...

error:
	LOG_ERR("gppi_channel_alloc failed with: %d\n", ch);
	return -ENODEV;
}

-12 means -ENOMEM

So it is trying to allocate a PPI channel, but it can't because it has used all it's resources (channels?). 

Are you using the SoftDevice controller as well as ESB?

You say that it takes several days to reproduce. Does that mean that the application has executed for several days before the issue occurs, or does it fail quickly after a reset/reboot?

Can you please confirm whether you did any (!) changes to the two files where this log comes from? That is, esb.c and esb_ppi.c?

Is esb_init() called several times in your application? Or just once at bootup?

Is esb_disabled called before each re-init attempt (if any)?

Do you have any logs from when the issue starts and/or stops? That is, the lines before the repeating two-liner, or the lines when it manages to recover from it? Do they say anything interesting?

Best regards,

Edvin

[Leo Mo]

Hi Edvin,

Q: Are you using the SoftDevice controller as well as ESB?

A: I'm using SoftDevice(BLE peripheral) and ESB.

Q: You say that it takes several days to reproduce. Does that mean that the application has executed for several days before the issue occurs, or does it fail quickly after a reset/reboot?

A:It had been running for several days before the problem occurred.

Q: Can you please confirm whether you did any (!) changes to the two files where this log comes from? That is, esb.c and esb_ppi.c?

A:The code for esb.c and esb_ppi.c comes from here:subsys: esb: improve resource cleanup on init error paths by maje-emb · Pull Request #29998 · nrfconnect/sdk-nrf

Q: Is esb_init() called several times in your application? Or just once at bootup?

A: Yes, esb_init() and esb_start_rx() are called every 4 seconds; then esb_disable() is called again after waiting 8-10 milliseconds, and this cycle repeats.

Q; Do you have any logs from when the issue starts and/or stops? That is, the lines before the repeating two-liner, or the lines when it manages to recover from it? Do they say anything interesting?

A: Sorry, no other logs were captured at the moment.

Best regards,

Leo

[Leo Mo]

Hi Edvin,

I encountered a similar issue during my tests using the nRF52840DK. You can open the esb_prx_ble_test_0917.log file and search for "HARD FAULT" to see the specific details.

Based on NCS v3.3.0.
Test Steps:
1. Burn esb_prx_ble_test.hex to the nRF52840DK.

2. View the logs using J-Link Viewer.

3. The nRF52840DK will scan for nearby BT devices (RSSI>=-50) and attempt to connect.

4. If the connection is successful, it will disconnect after 5 seconds.

5. Steps 3 and 4 will be automatically repeated.

esb_prx_ble_test_0917.log

esb_prx_ble_test.hex

esb_prx_ble_test.zip

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,

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