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

[Ole Bauck]

DEADBEEF means an assert from the SoftDevice and comes from softdevice_assertion_handler(uint32_t pc, uint16_t line_num, const uint8_t * file_name) which calls assert_nrf_callback(line_num, file_name) which in turn calls app_error_handler(DEAD_BEEF, line_num, p_file_name), where DEAD_BEEF is defined as 0xDEADBEEF. Could you give me the line number and file name that was used in the app_error_handler, so I can check where it comes from?

Edit 11.01.2016:

##NRF_ERROR_BUSY

You can get this if you try to connect and there are still events in the event buffer. You will also get it if you call sd_ble_gattc_write while another write is ongoing. Waiting for write complete is sufficient.

##NRF_ERROR_INVALID_STATE

We cannot give you a list over all states, so there is no automatic way to handle this error. If you try to connect without advertising you will get this error, or if you already try to initiate a new connection.

[Marius Heil]

I found out that I could reproduce one of the asserts by stress testing multiple nodes. I do not have a debugger attached and I am outputting many messages on uart. They are now sending a lot of connection packets, advertising, scanning and connecting, all 25 seconds rebooting, all at the same time. Now, after a while most of my nodes will crash at the line where I call sd_ble_gap_adv_start(). I have a uart output right before and right after this call and the second output is not sent. While I had the debugger attached (from the start of the node) this was similar and resulted in a softdevice assert at "src\ll_ctrl.c" at line 2605. Without the debugger, the assert handler was called as well, which I could verify by setting and LED.

The params that I am giving to sd_ble_gap_adv_start are at the address 0x20003888 which is a static variable.