How to read state of ble advertising in nrf5340

Hi,

Is there an API, data structure or else in nCS v2.9.0, monitoring of which i can understand if ble advertisement is active or not active or at fault.?
Also, if at fault to trace the type of fault.?

Facing an issue wherein ble adv abruptly stops after a brief while, yet device stays on. And post device reset adv starts again. 

Regards, 

Parents
  • Hi,

    There is no API that lets you check if advertising is ongoing. You will need to keep track of this yourself, by handling relevant callbacks. For a connectable advertiser, advertising is stopped when a connection is established. Then y ou typically may want to re-start advertisign when a connection is terminated (this si demonstrated in most BLE peripheral samples). Also, if you create an advertising set with bt_le_ext_adv_create you can pass a instance of the bt_le_ext_adv_cb with callbacks for various consitions, such as timeout.

    The case you are seeing, is the time before advertising stops fixed? Could it be that a timeout is specified or that you have some code that explicitly stops it after some time or in certain conditions?

  • Hi  ,

    I did monitor the connection event callbacks, and seems the drop in advertisement does seem to flow through the callbacks.

    Hence checking if anything at lower level i can monitor

  • Hi,

    Mohammed Ubaid said:
    I did monitor the connection event callbacks, and seems the drop in advertisement does seem to flow through the callbacks.

    I did not fully get that. Can you elaborate?

    Mohammed Ubaid said:
    Hence checking if anything at lower level i can monitor

    For connections you have the Radio notifications callback, but that does not work for advertising. A potential low-level solution provided you do not do anyting else with the radio (including no scanning or connection at this time), is to check for events form the RADIO. You can for instance hook that up to the EGU via PPI. I do not have an example of that, but connectin gradio events to PPI is demonstrated in the ppi_trace sample. And the EGU is demonstrated here.

    PS: I would still focus on the root cause though. You write that you recover by resetting. Is the problem on the network core? Do you have logging from the network core?

Reply
  • Hi,

    Mohammed Ubaid said:
    I did monitor the connection event callbacks, and seems the drop in advertisement does seem to flow through the callbacks.

    I did not fully get that. Can you elaborate?

    Mohammed Ubaid said:
    Hence checking if anything at lower level i can monitor

    For connections you have the Radio notifications callback, but that does not work for advertising. A potential low-level solution provided you do not do anyting else with the radio (including no scanning or connection at this time), is to check for events form the RADIO. You can for instance hook that up to the EGU via PPI. I do not have an example of that, but connectin gradio events to PPI is demonstrated in the ppi_trace sample. And the EGU is demonstrated here.

    PS: I would still focus on the root cause though. You write that you recover by resetting. Is the problem on the network core? Do you have logging from the network core?

Children
  • I did not fully get that. Can you elaborate?

    I mean to say that when advertisement stops the breakpoinbt doesn't hit the connected & disconnected callbacks.

    	/** @brief Channel disconnected callback
    	 *
    	 *  If this callback is provided it will be called whenever the
    	 *  channel is disconnected, including when a connection gets
    	 *  rejected.
    	 *
    	 *  @param chan The channel that has been Disconnected
    	 */
    	void (*disconnected)(struct bt_l2cap_chan *chan);

    A potential low-level solution provided you do not do anyting else with the radio (including no scanning or connection at this time), is to check for events form the RADIO. You can for instance hook that up to the EGU via PPI. I do not have an example of that, but connectin gradio events to PPI is demonstrated in the ppi_trace sample. And the EGU is demonstrated here.

    This i shall try.


    PS: I would still focus on the root cause though. You write that you recover by resetting. Is the problem on the network core? Do you have logging from the network core?

    Yes enabled net core logging but nothing there, any specific debug logs i can enable through prj.conf for monitoring adv event logs.?

  • Hi,

    Mohammed Ubaid said:
    I mean to say that when advertisement stops the breakpoinbt doesn't hit the connected & disconnected callbacks.

    Do you have timeout for advertising? If so, and you use the exgterned advertising API, ou cna get a callbackf for when that happens. Is there more you can say about in what circumstances advertising stops? It would be interseting to get to the root cause of this, as it really should not "just" stop by itself.

    Mohammed Ubaid said:
    Yes enabled net core logging but nothing there, any specific debug logs i can enable through prj.conf for monitoring adv event logs.?

    Not advertsing related specifically, but you can add debug logging using for instance CONFIG_BT_LOG_LEVEL_INF or CONFIG_BT_LOG_LEVEL_DBG

Related