BLE Multiple Central single Peripheral scenario

[LuisSilva]

Hi,

I’m currently experiencing some periodic MCU resets while testing the BLE Multiple central single peripheral scenario, whose root cause is not clear to me, except that the reset reason is watchdog related and happening in specific situations.

Scenario:

- I’m using nrf52832, SDK16.0.0 and s132nrf52701 and not using peer manager module, i.e., not using pairing/bonding for the BLE connectivity.

- Initially I had a single Peripheral device and multiple Central devices, where each Central could periodically report its status to the Peripheral.

 -- I followed Nordic examples, using only single Central and single Peripheral and it worked having still multiple Centrals performing the reporting at the same Peripheral without issues.

 -- I.e., I only considered NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1 ,  NRF_SDH_BLE_CENTRAL_LINK_COUNT 1 and NRF_SDH_BLE_TOTAL_LINK_COUNT 2 and did not consider any multiple concurrent connections.

 -- In this 1-Peripheral N-Central scenario I had no reset issues even if not explicitly using multi concurrent connection approach.

- Then, due to distance coverage, I wanted to implement a Mesh scenario, where the device previously always considered as Peripheral could itself change its BLE Role to Central so that it could follow the devices’ statuses (including its)  to its Peripheral and then change back to its Peripheral Role again.

  -- Initially, I still have not considered any multiple concurrent (Central) connections approach without success, meaning the Peripheral would crash.

  -- I then changed the support to multiple concurrent connections (e.g., changed the LINK COUNTs, Queued Write initialization and did not consider single m_conn_handle variable…) also without success.

 

Questions:

#1 – Is it still important to have multi concurrent connection support if not having Peer Management?

I.e., in which situations would it really fail for my initial approach?  

#2 – What is the correct SDH_BLE_<PERIPHERAL|CENTRAL|TOTAL>_LINK_COUNT setting and its use in the initialization when willing to support single Peripheral device and 5 Central devices reporting to the Peripheral device? Is it:

- NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 5 (as Peripheral a device can only be connected to from 5 Central devices)

- NRF_SDH_BLE_CENTRAL_LINK_COUNT 1 (as Central a device can only connect to a single Peripheral device),

Or instead the one below?

- NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1 (as Central a device can only connect to a single Peripheral device ) and

-NRF_SDH_BLE_CENTRAL_LINK_COUNT 5 (as Peripheral a device can only be connected from 5 Central devices)

Additionally, I assume that NRF_SDH_BLE_TOTAL_LINK_COUNT 6 (i.e., the sum of the previous), right?

 Moreover, when initializing the Queue Write (which I do not used, i.e., NRF_BLE_QWR_ENABLED 1 but NRF_BLE_QWR_MAX_ATTR 0), do we have to consider only 5 or 6 (the total) connections?

 

#3 – Do you recommend any example code emulating mesh, i.e., where a device behaves as a Peripheral to receive status but after aggregating some statuses, change its role to Central in order to communicate to its own Peripheral and only then change back to Peripheral?

#4 - Is there any configuration (e.g., from sdk_config.h) which could help understand where the MCU was hanged before watchdog being triggered?

Thanks in advance for you feedback.

Luis

[ovrebekk]

Hi 

  -- Initially, I still have not considered any multiple concurrent (Central) connections approach without success, meaning the Peripheral would crash.

So you mean to say that even in the scenario where you only run either central or peripheral (not both at the same time) you will experience crashes?

#1 – Is it still important to have multi concurrent connection support if not having Peer Management?

I.e., in which situations would it really fail for my initial approach?  

I am not sure I understand this question. If you only want to switch between peripheral and central role, or run one of each, you just need to set NRF_SDH_BLE_PERIPHERAL_LINK_COUNT  to 1, NRF_SDH_BLE_CENTRAL_LINK_COUNT to 1 and the total count to 2. 

#2 – What is the correct SDH_BLE_<PERIPHERAL|CENTRAL|TOTAL>_LINK_COUNT setting and its use in the initialization when willing to support single Peripheral device and 5 Central devices reporting to the Peripheral device?

In order to be connected to 5 central devices (as a peripheral) and 1 peripheral device (as central) you need the following settings:

NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
NRF_SDH_BLE_CENTRAL_LINK_COUNT 5
NRF_SDH_BLE_TOTAL_LINK_COUNT 6

 Moreover, when initializing the Queue Write (which I do not used, i.e., NRF_BLE_QWR_ENABLED 1 but NRF_BLE_QWR_MAX_ATTR 0), do we have to consider only 5 or 6 (the total) connections?

Are you planning to use queued writes at all?

If not you don't need to use this module. 

#3 – Do you recommend any example code emulating mesh, i.e., where a device behaves as a Peripheral to receive status but after aggregating some statuses, change its role to Central in order to communicate to its own Peripheral and only then change back to Peripheral?

Unfortunately we don't have any good examples showing how to establish a mesh using standard Bluetooth connections. 

We have support for Bluetooth mesh, but his is based on advertise packets rather than connections, and we have support for mesh through our Zigbee and Thread examples. 

#4 - Is there any configuration (e.g., from sdk_config.h) which could help understand where the MCU was hanged before watchdog being triggered?

Did you try to use the debugger? 

Then you should be able to check where in the code you end up when the crash happens. 

Best regards
Torbjørn

[LuisSilva]

Hi Torbjørn,

Thanks a lot for the feedback support.

It surely helps narrow down the troubleshooting and I had already identified some problems in my code.

1) If I do not emulate mesh, then I have no issue with specifying only one central and one peripheral but in fact using Peripheral 1: 2 Central.

Probably I have been very lucky, since even forcing high data exchange rate I could not have a crash.

2) Thanks for the clarification.

Specification only states maximum peripheral or central count, but I wanted to confirm its real meaning. I.e., NRF_SDH_BLE_(as a Central I can connect to)PERIPHERAL_LINK_COUNT and NRF_SDH_BLE_(as Periheral I can accept)CENTRAL_LINK_COUNT.

3) Ok. Thanks anyway

4) Yes, but it is not been easy testing BLE.

 

Thanks again for the support. 

Rgds,

Luis Silva

[ovrebekk]

Hi Luis

1) Ok, so it is when you change roles from peripheral to central or vice versa that you get crashes?

2) The critical aspect is to know that the PERIPHERAL or CENTRAL link count defines refer to the local role (what role you are running), not the role of the devices you connect to. 

If you want to connect to a central device you need to be a peripheral, and you need to increase the peripheral link count locally. 

4) Debugging when running a SoftDevice is not easy, as you can not start the code again once you stop (without first doing a reset), but it should be possible to set a breakpoint if you know where the error happens. 

Best regards
Torbjørn

[LuisSilva]

Hi Torbjørn,

Thanks a again for all the support. 

1) Crashing is really only happening when trying to emulate mesh, i.e., when having a device changing its role. It is due to a watchdog (triggers receive wdt_event_handler) and apparently when changing from Central to Peripheral and then quickly to Central again to report the status to the Peripheral. 

However, the crash sometimes happens not on the device that changes from Central<->Peripheral but also at its Peripheral, which only acts as Peripheral.

I'm also trying to assure any advertising before changing/acting as a Central role temporarely. Can advertising while in  Central role trigger a watchdog?

Not sure but it may be that I'm sending the device to sleep too soon and then SD triggers the wdt!?! Can it be?

Are there any general guidelines to follow prior to putting the device to sleep when it supports BLE connectivity? I.e., I really want to assure that I just put the device to sleep if it would not cause any watchdog from BLE (if it would be really the case, not sure). 

2) Prettry clear now. I was considering it wrongly before.

Thanks again,

Best regards,

Luis

[ovrebekk]

Hi Luis

1) What happens if you disable the watchdog then? Is the application running OK?

How fast is the watchdog set to time out?

LuisSilva said:

Not sure but it may be that I'm sending the device to sleep too soon and then SD triggers the wdt!?! Can it be?

The important thing when using a watchdog is to ensure to reset it often enough during normal operation, so you only get a watchdog reset if something abnormal happens (such as a deadlock in the code). 

If the watchdog is running in sleep you need to make sure you wake up often enough to reset it. 

LuisSilva said:

Are there any general guidelines to follow prior to putting the device to sleep when it supports BLE connectivity? 

No, normally going to sleep should not pose any problems. All our standard examples go to sleep as soon as the application has finished all its processing, handled any events etc. 

Best regards
Torbjørn

[LuisSilva]

Hi Torbjørn,

Thanks a lot for your continuous support. This thread can be now closed.

The watchdog issue is solved. It was being triggered because I was not periorically resetting (feeding) the WDT while in sleep.

Best regards,

Luis Silva

[ovrebekk]

Hi Luis

Thanks for sharing the solution.

Good to hear you found the issue

Best regards
Torbjørn