ble_app_uart_c_pca10056_s140 fails with an assertion

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Jørgen Holmefjord — Mon, 12 Mar 2018 09:54:27 GMT

Happy to help!

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Rob Philip — Fri, 09 Mar 2018 15:11:46 GMT

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.

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Jørgen Holmefjord — Fri, 09 Mar 2018 15:05:35 GMT

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.

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Jørgen Holmefjord — Fri, 09 Mar 2018 14:59:25 GMT

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

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Rob Philip — Fri, 09 Mar 2018 14:58:21 GMT

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.

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Rob Philip — Fri, 09 Mar 2018 14:41:12 GMT

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.

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Jørgen Holmefjord — Fri, 09 Mar 2018 14:08:57 GMT

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

RE: ble_app_uart_c_pca10056_s140 fails with an assertion

Rob Philip — Fri, 09 Mar 2018 10:41:42 GMT

also, FWIW, the serial printout on the uart is:

"BLE UART central example started."