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,

Please answer regarding my secondary question:

The reference manual 'CLOCK' section says that to use the RADIO an external crystal oscillator MUST be used however after initializing the soft device and checking HFCLKSTAT, it says the RC is being used. Is the crystal oscillator turned on dynamically for BLE RADIO use?

The reason this is important is I get RADIO traffic in both directions yet at no time do I check and find the crystal oscillator enabled (on the PCA10001s or my PCBs) so if it never needs to or gets enabled, I can rule out the crystal.

In addition can you confirm that the stack error that is thrown (reported in many posts now) results from clock/crystal selection/functioning/instability/accuracy. I.e. Does it have anything to do with anything affected by the clock.

One more note: The PCA10001s have QQFAA GC chips and my PCBs have QFAA C0 chips. All documentation I have found suggest I do not need to consider the differences between these two production codes.

[Ole Morten]

The crystal is turned on only for the actual connection and advertising events when using a softdevice. This is handled automatically by the softdevice. This means that the crystal will be on only for very short periods (few ms).

To verify the crystal is working, you can either do a radio test (DTM or radio_test_example), and check that the carrier is where you're expecting, or manually start the crystal (TASKS_HFCLKSTART in NRF_CLOCK) and use a sniffer probe to see it.

The assert you're seeing would normally be triggered only by application interrupts running with too high priority, but the fact that that you only see the problem with your custom board makes me suspect a crystal problem.

I'd still be very happy if you could post this separately, as this seems to become rather messy. I'd also like to see your complete source code and board schematics. If you don't want to share it here, feel free to create a regular support case.