ble_app_interactive example crashes

[bjammin]

Hi - I built and flashed the ble_app_interactive example from both SDK 15.3 and then from 16.0 on to my nrf52840 DK (PCA10056). I connect to a Thingy52, issue the gatt services command, and then the nrf52840 faults. I've been trying to step through in the SES debugger to find where it is, but haven't had much success. Note that this is the example from the SDK unmodified. Any thoughts on what to try next?

uart_cli:~$ connect F7:C8:CD:5E:19:DF

app: CENTRAL: Connecting...

Connected to address: F7 C8 CD 5E 19 DF

app: CENTRAL: Connected, handle: 0.

Current MTU: 276

MTU changed successfully

app: Data length updated to 251 bytes.

Connection parameters update success

uart_cli:~$ gatt services F7:C8:CD:5E:19:DF

hardfault: HARD FAULT at 0x0003A9D4

hardfault: R0: 0x2000ABDC R1: 0x20040000 R2: 0x0007FD18 R3: 0xFFFFFFFF

hardfault: R12: 0x2000A8FC LR: 0x00030F7B PSR: 0x21000226

hardfault: Cause: Data bus error (PC value stacked for the exception return points to the instruction that caused the fault).

hardfault: Bus Fault Address: 0x20040000

BLE app with command line interface example started.

Press Tab to view all available commands.

[Vidar Berg]

Hi,

I was able to reproduce this. Turns out the app will hardfault if it discovers more than "MAX_SERVICE_COUNT" services on the device it's connected to. You can increase the MAX_SERVICE_COUNT and MAX_CHARACTERISTIC_COUNT values in the sdk_config.h header to fix this. 

Where the fault occurred in my case (happens as soon as the offset value becomes larger than the MAX_SERVICE_COUNT setting):

[bjammin]

Fantastic, that was it. Thank you.

One more question on a different note: As I was stepping through the code in SES, stepping through main and various functions, I would inevitably end up in app_error_weak.c line 100: 

NRF_BREAKPOINT_COND

// On assert, the system can only recover with a reset.

I couldn't step over or out. Any idea how to get past that? It seems like I shouldn't end up there.

[Vidar Berg]

The Softdevice will eventually assert if you single-step or continue execution after hitting a breakpoint because it breaks its real-time requirements. So this is a known debugging limitation when you have the Softdevice enabled.  Monitor mode debugging is an option that lets you work around it if you are interested: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/monitor-mode-debugging-with-j-link-and-gdbeclipse 

[bjammin]

Thanks again! I had seen that link when I was searching before but for some reason thought this was something different. That affirms it. Thanks for the quick response.