DEADBEEF from somewhere in SD, both production and alpha

[Frank Zhao]

The error I get is app_error_handler 0xDEADBEEF, 360 (line number), src\ll_lm.s0.c

This is with SD 5.2.1

With SD 6.0.0.1-alpha, sometimes I get

app_error_handler 0xDEADBEEF, 783, src\ll_lm.s0.c

What my code does is initialize SoftDevice and start advertising, and it does a few hardware things, starts up one app_timer, then goes into my application loop

Sometimes, my application will run just fine forever, service discovery works, and I can send data back and forth between MCP and my app

Sometimes my loop will run only a few times, and then just freeze, with no error message, but it won't reply to service discovery.

Sometimes my loop will run only a few times, and then output the error message.

Sometimes my loop will run forever, until an attempt at service discovery, at which point I get the error message

This also sounds similar to devzone.nordicsemi.com/.../spurious-s110-crash except with different line numbers

edit: disabling the UART (not initializing it at all and not sending any characters) does not help, the advertising packet is sent only once, and fails to reply to service discovery

edit: there are no interrupts in my application, although I do have one application timer that fires an event handler every 1 millisecond

edit: I added a printf into my app_timer event handler, now sometimes I get "app_error_handler 0xDEADBEEF, 631, src\ll_adv.c", once in every maybe 10 attempts, using 6.0.0.1-alpha

edit: I got line 728 from src\ll_lm.s0.c just once so far, using 6.0.0.1-alpha

[Keith Gravlin]

Ole,

New information. In working to break my project/code down to the smallest possible set that exhibits the problem I have found the following:

When my code is minimized I am effectively left with the SDK V4.4.2 PCA10001 app_proximity_demo project. So I simply opened that project and performed the same test on both chips.

A note about my code: In order to debug my app without the softdevice running (so I can actually debug) I found I had to manually initialize the LFCLK because app_timer which I use depends on it and 'it' ASSUMES the softdevice is running by run time. BAD ASSUMPTION since it doesn't initialize either (this should be noted in the docs (at least) if not changed)!.

In any case when I do the manual initialization I am able to fully debug my app without the softdevice. Hooray! When I, in my full code, do enable the softdevice it doesn't seem to mind that the LFCLK is already initialized.

End of note about my code back to app_proximity_demo.

When I build and run the SDK V4.4.2 PCA10001 app_proximity_demo, it never returns from ble_stack_handler_init.

Just for fun I decided to manually initialize LFCLK in the demo code prior to ble_stack_handler_init and it then returns from ble_stack_handler_init and functions exactly like my full app. I.e. soon after connect it (not everytime but often) throws the DEADBEEF @ line 360 in src\ll_lm_s0.c error.

Whether it throws the error or not the connection is always lost.

So for code you can use SDK V4.4.2 PCA10001 app_proximity_demo.

Remember the demo works (with OR without the manual LFCLK init) on my PCA10001 PCB with a QFAAGC chip but does not on my PCB with a QFAAC0 chip (so unless you have a C0 chip you may not be able to duplicate).

Neither my app nor the proximity demo app DEPEND on any external signal. I have confirmed functionality of my power supply and you have helped me confirm functionality of my crystal leaving only the C0 chip (Nordic's), code (Nordic's), RF section (Nordic's design precisely reproduced). Also remember some amount of BLE traffic occurs in both directions per MCP just not all or forever.

I would welcome finding out this is something I am doing so I can fix it quickly however except for the LFCLK init (if I even include it) it it 100% SDK V4.4.2 PCA10001 app_proximity_demo that produces the problem.

Thanks for all your help, Keith Gravlin

[Keith Gravlin]

Ole,

A correction: My PCA10001 has a QFAAG0 chip.

Keith

[Keith Gravlin]

Ole,

Just to confirm I went back to my original full app on my PCB with the C0 chip and it also does not return from sd_softdevice_enable unless I precede it with the manual initialization of LFCLK and of course it still has the connect exception issue when I do.

Keith

[Ole Morten]

Debugging an application without the softdevice on it is meaningless. There shouldn't be any problems with running an application in the debugger, and you can also perfectly fine halt on breakpoints. The only thing you can't do is to call softdevice function or have interrupts trigger if you run onwards after having halted on a breakpoint.

Manually initializing the LFCLK before enabling the softdevice is not needed, and I can't see how that changes anything.

I've worked extensively with both the C0 and the FA (equal to G0) revision of the nRF51822, and I've never seen any problems with either of the above.

Can you please try to do the following:

1. Program the appropriate softdevice to your custom board
2. Make sure that the app_error_handler of your application does not contain a reset, and that the call to ble_debug_assert_handler is uncommented.
3. Run your application with the debugger.

If you believe that you've seen the problem, stop the CPU with the debugger and see where it is. If you do see the problem, please try changing the LFCLK source to using the RC oscillator, and try to see if that changes anything.

Please also supply the details of the crystals you're using, both the 16 MHz one and the 32 kHz.

As I've said before, you can create a support case if you need this to be handled in confidentiality. It might also give less messy back and forth, since this site is primarily targeted on answering questions, not debugging application problems.