Softdevice Assertion failure with ble_app_template

Question

Hi 
 I am currently developing a demo application and started with the ble_app_template project from the ble_peripheral_folder (s140 softdevice, sdk 16.0). I copied it to another folder and modified the paths in the Segger Embedded Studio project file to match the correct paths. I also modified the path to the S140 softdevice file. The board is a custom board which is roughly (very roughly) derived from the 52840 DK. In fact we're using a Nina B302 module (which contains the nrf52840). 
 This is the code for main so far: 
 int main(void)
{
 bool erase_bonds;

 // Initialize.
 log_init();
 timers_init();
 buttons_leds_init(&erase_bonds);
 power_management_init();
 ble_stack_init();
 gap_params_init();
 gatt_init();
 advertising_init();
 services_init();
 conn_params_init();
 peer_manager_init();

 // Start execution.
 NRF_LOG_INFO("Template example started.");
 application_timers_start();

 //advertising_start(erase_bonds);

 // enable 3V1_SW
 nrf_gpio_cfg_output(10);

 // Enter main loop.
 for (;;)
 {
 idle_state_handle();


 }
}

 
 My test project works as long as I comment out the line "advertising_start". As soon as that line is included (it returns 0x0, so no error), I won't get to the the next line (nrf_gpio_cfg_output) but it seems that the device will hang a while and then go to app_error_fault_handler (id = 1). 
 I am not quite sure if there is an issue with the softdevice because I copied the files somewhere else but I can hardly think that's the issue. Any ideas how I could debug this issue?

Edvin · Accepted Answer

Hello, 
 I suggest that you try to run the unmodified example from it's original location, just to check whether the issue is caused by differences in HW, or the fact that you moved the project to another folder. 
 
 Now, either way you probably want to know what causes the issue later on. Do you see any log output when you are debugging? If not, what backend does your log use? Search for NRF_LOG_BACKEND_RTT_ENABLED and NRF_LOG_BACKEND_UART_ENABLED in sdk_config.h of your project. 
 It probably uses UART by default. If you want the log in the debug view in segger embedded studio I recommend that you set: 
 NRF_LOG_BACKEND_UART_ENABLED 0 NRF_LOG_BACKEND_RTT_ENABLED 1 NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0 
 
 Now you should see your log in the debug view of your project. If you do, and you see this error message saying something like "fatal error", go to your project settings, select common (and not "release" or "debug") from the drop down menu, go to "Preprocessor" -> "Preprocessor Definitions" and add a line saying "DEBUG" in your preprocessor defines. 
 What does the log say then? 
 
 Best regards, 
 Edvin

Edvin · Answer

Hello Thomas, 
 
 thomas.l said: Is this expected behaviour? Is there something I need to change or is this the way it is? 
 Yes. This is expected. If you break during a debug session after the softdevice is enabled, you can't pause the execution. If you do this, the softdevice will miss some time critical events, and hence it behaves buggy in best case, and it will probably assert. 
 You can use breakpoints to see what's going on, and step a few times, but after that, you need to restart the application. 
 
 Another thing you may see: 
 If you run a debug session, and the advertising times out, the application will call sd_power_system_off() (usually from a function called sleep_mode_enter() ). If you are debugging, this will also return an error, because the chip will not be able to shut down when you are debugging. This is also expected, and will not happen when you are not debugging. 
 
 Best regards, 
 Edvin

Softdevice Assertion failure with ble_app_template

Top Replies