This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DEADBEEF from somewhere in SD, both production and alpha

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

  • I got more to report

    Now I'm doing another completely different firmware

    Now I can never send more than one advertising packet before it just halts

    And I get some more DEADBEEF crashes, such as

    app_error_handler 0xDEADBEEF, 631, src\ll_adv.c

    app_error_handler 0xDEADBEEF, 728, src\ll_adv.c

    or sometimes it just freezes

    using SD 6.0.0.1-a

  • updated to today's new SDK 4.4.3, no improvement in behaviour at all

  • Hi,

    Are you sure you haven't enabled any IRQs with priority 0 or with unset priority which will be 0 (which can happen if the sd_nvic_* calls are not used for this), and that you don't disable all interrupts from the application?

  • Sorry for not noticing this question before, but it didn't show up in "Unanswered" questions, since you had answered it several times yourself.

    However, this isn't something that should happen, and the only way I can think of that could cause this kind of behavior is if you use illegal interrupt priorities in your applicaiton, as Øyvind suggests. When the softdevice is enabled, you are not allowed to have any interrupts with priorities 0 or 2. If you use the sd_nvic_* functions to manipulate the interrupts, the softdevice will ensure that you comply with this, but if you use the NVIC_* functions directly, there are no such checks. Take a look at this question for further details on the difference between those interfaces.

    I'd therefore recommend you to go through your application and make sure that you use the sd_nvic_* functions for all your own interrupts, and make sure that they have legal priorities.

    For an explanation of how the softdevice works, it is useful to take a look at the appendix of the nRF51 Reference Manual.

    If you're still not able to solve this problem, can you please share the complete source code of your project? If you need confidentiality, feel free to create a support case for it, instead of posting it here.

  • Ole,

    My application has been working flawlessly on PCA10001s but now that I have my first two custom PCBs, I am having the same issue described in the original question: "The error I get is app_error_handler 0xDEADBEEF, 360 (line number), src\ll_lm.s0.c

    This is with SD 5.2.1"

    I have not tried this with any version of SD 6.

    Big difference: I do not use any interrupts, I use only app_timer functionality.

    If I flash the code into a PCA10001 (I have four) I never see the error but my first two custom PCBs both throw this error soon after receiving a BLE_GAP_EVT_CONNECTED.

    My app doesn't depend on any external signals so I'm not sure how it could run differently on my PCB vs the PCA10001s. Both the PCA10001s and my PCBs have QFAA chips.

    Any thoughts?

    Another question (as I tried to figure out how the code could run differently on a different chip): 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?

Related