BLE Peripheral connected to multiple Central devices on nrf52840 DK and SDK V16.0.0 (revisited)

[AndersF]

Hello.

I am running Segger studio 4.5 on Windows 10 and the ble_app_uart example project that works fine with one connected central device (i.e. iPhone with nRF Toolbox running UART).

Now I would like to have two such connections.

I found this exact question answered here:
https://devzone.nordicsemi.com/f/nordic-q-a/58710/ble-peripheral-nus-connected-to-multiple-central-devices-on-nrf52840-s140-and-sdk-v16-0-0/239409#239409 

And while that thread solved the problem that time, it does not work for me now...

I have changed RAM size and location as suggested, and BOTH link counts in sdk.config.h.
(Stopping at NRF_LOG_WARNING("Change the RAM start location... etc. and set the following in the project options:
RAM_START=0x2000002C
RAM_SIZE=0x3FFD4)

For some reason I get no output in the "Debug Terminal" window during debugging, even though I set this in config:
#define NRF_LOG_ENABLED 1
#define NRF_LOG_DEFAULT_LEVEL 4

However, the code crashes during ble_stack_init() in nrf_drv_clock.c::sd_state_evt_handler() when trying to do CRITICAL_REGION_EXIT.

I have also run the project that was kindly made available as a zip-file in the thread above, but it crashes at the exact same spot.

Any ideas what's going on?

Thanks,

Anders.

[Simonr]

Hi Anders

Can you confirm that you've increased the NRF_SDH_BLE_TOTAL_LINK_COUNT define to the number of links you'd like to have, as well as the NRF_SDH_BLE_CENTRAL_LINK_COUNT? You have set the RAM_START and RAM_SIZE to the values requested by the SoftDevice as well, correct?

The reason you're not seeing debug messages is likely because you're using the RTT_backend (which the ble_app_uart example does by default). Try setting the NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED define to 0 in sdk_config.h and see if you're able to see the debug log that way?

Best regards,

Simon

[AndersF]

Thanks for you swift reply.

This is what I already have, and no output:

#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0

I assume you mean NRF_SDH_BLE_PERIPHERAL_LINK_COUNT?? ble_app_uart starts on 1 and I increased it to 2.

I have:

#define NRF_SDH_BLE_TOTAL_LINK_COUNT 2

#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 2

I don't know how much RAM the SoftDevice requires other than to set a breakpoint at:

NRF_LOG_WARNING("Change the RAM start location... in nrf_sdh_ble_enable() and get the variable values which gives me:

RAM_START=0x2000002C
RAM_SIZE=0x3FFD4

No complaint about the RAM size during execution after that...

[Simonr]

Where are you looking for this log output? You can download the J-Link RTT viewer for instance, which should print the debug log either way. You can also try changing the define to 1 if it's 0 already to see if that changes anything.

I'm sorry. I keep mixing those defines up... Can you confirm that the CENTRAL_LINK_COUNT is set to 0 if the two others are set to 2? I thought you saw this issue when increasing the LINK_COUNT beyond 2?

You can check out our guide on how to adjust RAM and Flash Memory according to the SoftDevice you're using.

Best regards,

Simon

[AndersF]

I have this config:

#define NRF_LOG_ENABLED 1

and 

#define NRF_LOG_BACKEND_RTT_ENABLED 1

I'm looking in the window called "Debug Terminal" in the image below.

I've also started the RTT viewer, and although it seems to get a connection, there is no output from the various printouts like the ones in main.c:

printf("\r\nUART started.\r\n");
NRF_LOG_INFO("Debug logging for UART over RTT started.");

I find this very confusing. Where is the printf and NRF_LOG_INFO supposed to end up, and why are both used??

Oh, hang on... if I put a breakpoint before the NRF_LOG_INFO statement and wait a few seconds before continuing execution, the RTT viewer actually prints. So it needs some time to start up then. Problem solved!

I have seen the RAM and FLASH guide. What I did was to take the value from p_app_ram_start, when in fact I should have taken the value from *p_app_ram_start, i.e. the value it's pointing to. Once I realized that, it seems to be working! Yeah!

Thanks for the speedy help.