What do DEADBEEF, NRF_ERROR_BUSY, NRF_ERROR_INVALID_STATE,... actually mean?

[Marius Heil]

Hello,

I am currently looking through my error handling and noticed that there are some errors that I do not really understand fully, so I've summarized them here:

0xDEADBEEF

One of my devices just ran into a DEADBEEF error and I am wondering where it comes from. My debug backtrace does not seem to be usable at this point.

Could you give us a list of possibilities that would cause a DEADBEEF error? What are the conditions of it being thrown?

And when there is one, how can I debug it properly and find the part in my code?

NRF_ERROR_BUSY

E.g. when creating a connection with sd_ble_gap_connect, does this error simply mean that there is no more free space in the event buffer so that I have to handle another event first before I can call this function, which will generate a new event?

Or as another example: sd_ble_gattc_write. Will the NRF_ERROR_BUSY only be thrown when another write is ongoing? If my routine does only send data after a Write complete has been received, I should be safe, right?

NRF_ERROR_INVALID_STATE

How many states does this include? I know of the typical ones for BLE like Connecting, Advertising, Scanning, etc.... but according to an answer of a forum question flash operation ongoing seems to be an additional state. Could you provide us with a list of states that will cause this error?

Somewhere in the documentation it says "Invalid state to perform operation (most probably not in advertising state).", which is not really helping because I do not want to do error handling based on guessing. I could not find a more detailed description for these error, sorry if I missed it somewhere.

Marius

[Martin Tverdal]

Hi, The second assert your are getting (pc: 65210 (0xfeba)) is quite common to get if your application is delaying the highest priority interrupt of the SoftDevice from executing.

Are you: 1. Using __disable_irq()/__enable_irq() or 2. Using the highest priority interrupt for some of your interrupt routines. or 3. Writing/erasing flash without using the sd_flash_write or sd_flash_page_erase

If you are not doing either 1, 2 or 3 do you have any idea of what is happening when the assert happens. Is the device scanning or advertising? is it in a connection? if so, what is the connection interval you are using?

Just to make sure, you are using nrf51 and not nrf52 right?

[Marius Heil]

Hello,

my event handling routine loops with sd_ble_evt_get and if no event is available, it calls sd_app_evt_wait followed by sd_nvic_ClearPendingIRQ(SD_EVT_IRQn).

I am not using any more interrupts in my code, but I do use the app_timer library which does probably do some interrupt handling. I was not writing to the flash memory at the time when the interrupt happened. Besides I only use sd_flash_... calls.

As I stated above, this seemed to happen after a call to sd_ble_evt_get but I cannot tell you whether advertising or scanning was enabled. The device was probably in a connection and I guess that it was not advertising or scanning. I will pay closer attention if this happens another time, and I can also leave it in the debugging state to find out more. This was the first time I got that error and it hasn't happened since, but I will keep watching.

I am using the nRF51 chipset.