ble_app_uart_c_pca10056_s140 fails with an assertion

[Rob Philip]

ble_app_uart_c_pca10056_s140 fails with an assertion - I have downloaded nRF5_SDK_14.2.0_17b948a. For the example project examples\ble_central\ble_app_uart_c\pca10056\s140\ses I modified sdk_config.h values NRF_LOG_DEFERRED 0 and built the project with the segger tools. The project downloads the s140 soft device, and my code when I debug the project. However, in my debug terminal window I see:

nrf_sdh_ble: RAM starts at 0x20002978, can be adjusted to 0x20002668.
nrf_sdh_ble: RAM size can be adjusted to 0x3D998.
app: BLE UART central example started.
app: SOFTDEVICE: ASSERTION FAILED

The assert happens on line 152 of main.c when "ret" is checked for success. It *is* success, but nonetheless APP_ERROR_CHECK fails.

static void scan_start(void)
{
ret_code_t ret;

ret = sd_ble_gap_scan_start(&m_scan_params);
APP_ERROR_CHECK(ret);

ret = bsp_indication_set(BSP_INDICATE_SCANNING);
APP_ERROR_CHECK(ret);
}

FWIW the identical problem occurs using the Keil tools. Thoughts?

[Jørgen Holmefjord]

Hi,

Did you modify the example more than disabling deferred logging? The example should not generate a softdevice assert with this change. APP_ERROR_CHECK should also not fail if no error code is passed to it. Are you sure there is nothing happening at the same time that is causing the softdevice assert? Are you using the correct softdevice version supported by the SDK version?

Best regards,
Jørgen

[Rob Philip]

I only turned off deferred logging because the application failed and I was hoping for more information.

If you look under "debug->loader" for the project you'll see that the

Additional Load File[0]
Additional file to load on debug load. This property will have macro expansion applied to it.
Inherits
"../../../../../../components/softdevice/s140/hex/s140_nrf52840_5.0.0-2.alpha_softdevice.hex" from project in Common configuration

 I can only trust that the developer of the example chose the correct soft device. 

This example fails out of the box - you can literally reproduce it by unzipping nRF5_SDK_14.2.0_17b948a, doubleclicking nRF5_SDK_14.2.0_17b948a\examples\ble_central\ble_app_uart_c\pca10056\s140\ses\ble_app_uart_c_pca10056_s140.emProject, building and debugging. You won't need to do anything but tell the debugger to "go". 

There is no BLE activity (which is what caused me to investigate) and the example should have asserted (not that you can tell, because it doesn't print anything). If you turn off deferred logging you'll see the "asserted" printout and you'll be in app_error_fault_handler.

[Rob Philip]

OK. It's more subtle a problem than I described. Without any single-stepping or breakpoints (other than in app_error_faulthandler) the app does *NOT* assert. Nor does it work. 

No BT devices appear when the app is running. 

Any single-stepping of the initialization for the app and the assert happens. 

Of course, I was only single-stepping because the app didn't seem to work. 

[Jørgen Holmefjord]

I'm not able to reproduce this issue by following your steps. Which version of the nRF52840 PDK are you using? Which SES version? 

[Jørgen Holmefjord]

I see, that makes sense. The softdevice will always asser if it is not able to handle the received events (which will happen when you set a breakpoint that will halt the CPU). Note that you are trying to run a central application. This will not advertise and show up as a BLE device on your phone etc. This is an example that will scan for devices advertising the UUID of the Nordic UART service. You can test it by running the ble_app_uart (peripheral) example on a second board.

[Rob Philip]

Aargh! 

Indeed, that was the problem. The central & peripheral apps *look* the same and I had not (for some reason) noticed the "documentation" directory. 

Thanks for your help - I'm an idiot. In my defense, I hadn't even heard of Nordic a week ago.

Feel free to close this ticket.