Intermittent problem restarting advertising: ENOMEM, failed to create advertising set

[cscase]

Hi all,

Short problem description: I am troubleshooting an issue with the nRF5340 wherein the device runs for some time, then eventually gets stuck with an err -12 (ENOMEM) when attempting to create an extended advertising set.

This is on a custom board with the Fanstel nRF5340 module. I am using nRF Connect SDK 1.7.1. I cannot upgrade this, because we have already made a declaration with the Bluetooth SIG for this product. I am using hci_rpmsg on the net core. The code I am troubleshooting runs on the app core.

There are two execution paths by which advertising gets restarted:

1) During normal operation, occasionally the app core receives updated manufacturer data for advertisement via SPI. When this happens, advertising is stopped, the advertising set is deleted, a new one created, and advertising is restarted. Normally, this mechanism will work fine, with no problems and runs indefinitely.

2) When a Bluetooth connection is established, advertising stops (by design). After the connection ends, in the callback for the disconnect, a worker task is queued up to restart advertising. this task does not delete or update the advertising set - it merely restarts advertising.

What happens is that if I connect to the device repeatedly - sometimes after 12 times, other times it might take 300 times - eventually I enter a state where the device has disconnected from Bluetooth and is trying to restart advertising and keeps getting the error ENOMEM when attempting to create the advertising set.

I can increase the number of extended advertising sets allowed (CONFIG_BT_EXT_ADV_MAX_ADV_SET), as has been suggested in other posts I have seen, and I did try that but immediately started to see erratic behavior, so I backed off the change, and I wanted to ask here some questions:

• Is it better for me to, instead of increasing the number of advertising sets, to figure out what causes the problem and address it? The intent of the design is to have only one advertising set.
• If I catch this exception, could I have code in place that will resolve the issue automatically, perhaps by deleting old advertising sets or somehow re-initializing advertising? What should that look like?  
• Is it likely that this error occurs as a result of sloppy code on my side and could be prevented?

Thanks!

Scott

[RM]

Hi Scott,

Did you try to disable BT part and re-enable after a short delay in case of error?

Thanks,

Reuven

[cscase]

Thanks Reuven,

I have found that if I reset the nRF5340 via the J-Link (nrfjprog --pinreset), it returns to normal function. However, nothing else that I have found is able to recover it. Here is what I have in the reset routine currently. It does not allow advertising to resume.

      *(volatile uint32_t *) 0x40005618ul = 1ul;

      NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Release << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);

      k_msleep(5); // Wait for at least five microseconds

      NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Hold << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);

      k_msleep(1); // Wait for at least one microsecond

      NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Release << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);

      *(volatile uint32_t *) 0x40005618ul = 0ul;

NVIC_SystemReset();

[cscase]

To be more clear in my answer, to your question: I did try the things mentioned here, but I have not tried specifically disabling BT. If you think this is a good approach to take, I would be glad to give it a shot. How could I go about that? Thanks!

[RM]

In later SDK releases, there is bt_disable function in

ncs/v2.3.0/zephyr/subsys/bluetooth/host/hci_core.c

I think similar functionality should be achievable with 1.7.1

[kpreiss]

Hi Scott,

I am seeing the same behavior you've outlined above using an extended advertising set.  Using nrf Connect SDK v2.4, I am restarting extended advertising in another thread after a disconnect occurs.  In my situation, it always appears that an ENOMEM error is returned after calling bt_le_ext_adv_start() after the 4th disconnect.  The KCONFIG parameters being used... 

CONFIG_BT_MAX_CONN=4

CONFIG_BT_CTLR_ADV_SET=3
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=3

Best,

Kurt