Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF5 SDK 17: ble_app_blinky crashes when receives an Led status change request on button press over a custom board (other than listed in SDK)

Environment:

nRF5 SDK version: 17

SoftDevice: S140

Tool: Segger Embedded Studio

Debugger: J-Link EDU Mini

Board: Arduino Nano 33 BLE (Using SWD pins with the J-Link)

Processor: nRF52840

(Added a custom board file containing the pin definitions for the Arduino Nano 33 BLE. I used several standard non-ble peripheral examples, edited them heavily, and all worked fine with this board.)

Problem:

The following problem occurs when I try to use ble_app_blinky examples. For the rest of the text, let’s call the Board running Central ble_app_blinky as BLE_Cen, and let’s call the Board running Peripheral ble_app_blinky as BLE_Per.

BLE_Per not working correctly with BLE_Cen neither with the Android app. The connection is established successfully in both cases, but LED is not updated on pressing the button on one board or on the app. Led remains green all the time. But connection/disconnection works successfully.

After debugging, I noticed that the application crashes and goes to hard fault whenever I press the button on one board (say BLE_Cen), and the information is sent to the other board (say BLE_Per) via BLE. If I don't press the button, it keeps running and can make or break connections successfully. At pressing the button on one board I checked if it reaches the “led_write_handler(...)”. It does and executes the LED on/off code lines. However, it crashes afterward. I placed the breakpoint right after the line where this handler is called. It does not return, instead, it goes to some error and stops, pressing again, it starts and goes to a hard fault. I replaced the LED update code with a simple integer assignment to check if it is a problem with the led stuff, but the behavior remains the same.

I have not changed anything in the example code or configuration, just compiled and programmed the boards. I only added the custom board file containing the pin definitions for the Arduino Nano 33 BLE. Nothing else. And it is working with other non-ble peripheral examples as well as my own project code. The following are a few debugging details.

After successful connection (green LED on both boards), I press the button on BLE_Cent, BLE_per reaches the “led_write_handler(...)”, wherein I have placed a breakpoint to stop. Then I place a breakpoint at the next line where this led handler is called. This is in “nrf_sdh_ble_evts_poll(void * p_context)” at “if (ret_code != NRF_ERROR_NOT_FOUND)”. I press the run to continue execution. It crashes and never reaches the other breakpoint. It stops at “00000A60: 4B01  ldr r3, [PC, #4]”. When I press run to continue again, it stops at “NRF_BREAKPOINT_COND;” in “app_error_fault_handler(...)”.

If I execute without debugging, there is no effect on led on pressing the button. I am sure the same is happening in this case. It would be great if you can please help me in this regard.

  • Hello,

    I would suggest you start with enabling logging over RTT. This will make the debug log appear in the SES debug terminal window when you debug, and the log should tell you where the error occurred.

    All you need to do to enable RTT logging is to change the build configuration from "Release" to "Debug" and  change these two config settings in sdk_config.h:

    - NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0

    - NRF_LOG_BACKEND_RTT_ENABLED 1

  • Hi,

    @: Thank you very much for the useful information. It was new to me. It allows us to debug without stopping the program. The example code works. However, you also need breakpoints to debug your code. So, in my case, the program was crashing because of breakpoints, or due to stopping at the breakpoint(s), or pausing and re-starting the execution. This gave me the wrong information that the program is crashing due to some bug in the code. It seems there is some issue with the debugging. Can you please guide me on how to solve the debugging-crash issue. I observe the following in this regard.

    1- When I stop at a breakpoint in "led_write_handler(...)" and continue the execution, following is the debug output:

    <info> app_timer: RTC: initialized.
    <info> app: Blinky example started.
    <info> app: Connected
    <error> app: SOFTDEVICE: ASSERTION FAILED

    2- When I do not use any breakpoint, pause to see where is it at the moment, and re-start the execution, after some time it crashes. I see the following debug output:

    <info> app_timer: RTC: initialized.
    <info> app: Blinky example started.
    <info> app: Connected
    <info> app: Received LED ON!
    <info> app: Received LED OFF!
    <info> app: Received LED ON!
    <error> app: SOFTDEVICE: ASSERTION FAILED

    Thank you again for your kind support.

  • The Softdevice will assert if you continue execution after hitting a breakpoint. This is expected behavior, and the reason is that halting the CPU will break the timing requirements in the Softdevice. So you may have to use breakpoints a bit differently than what you are used to.

Related