DEADBEEF in my Code but from where?

[Nils Minor]

Hi,

i have a big Problem, if i debug my code i get in some cases in register 3 the value 0xDEADBEEF and after that the device doesn't work any longer in a correct way. No i had debugged a long time but can not discover where this error is from. I check all my priorities of the parts i used and the are all 3 or 1 and i used sd_... methods to do this.

Also if i change the vale of DEADBEEF which i have defined and which is used by my assert_handler nothing happens in debugging, thats why i think the eroor comes from some where else and doen't call the assert_handler. But this is the only value where i can find the codeword 0xDEADBEEF.

What could be a reason for this error and where does it come from. In my application i did not start advertising after i enabled the sd an after init i disabled it, could that be a problem?

I realy need some help, i don't know where to look in my code to get it work saftey.

thank you and best regards, Nils

[Ole Morten]

If you run your project with the debugger, it should be possible to see where it hangs when you stop it.

To be certain that you catch all errors, you should also remove the reset from app_error_handler, and make sure it contains an infinite loop of some kind. Doing so should show you where the error occurred, which again should help you find the actual problem.

If you still have trouble, can you please share your complete code, either here or in a support case, so that we can take a look?

[Nils Minor]

Hi Ole,

Thanks for helping me. I also thought that i can detect function which writes deadbeef in register 3 but it does not work or i do something wrong. From where is it possible to get thes deadbeef i can not find the word in my code, does it come from the softdevice? My app error handler is empty. If i do a breakpoint in the error handler an it wil be called how can i detect from where in the code the error handler is called ?

Thank you ole, best regards nils

[Ole Morten]

Did you actually read my reply? "Make sure [app_error_handler] contains an infinite loop of some kind. Doing so should show you where the error occurred, which again should help you find the actual problem." If you have an empty app_error_handler, you will for sure see strange behavior, since the program will keep on running when an error has occurred, and things are in an inconsistent state.

The file name and line number failing will be passed in the arguments of app_error_handler. If you have UART printout enabled, you can for example print them out over UART. If you use ble_debug_assert_handler, you should be able to inspect the variables from the debugger. Keil tend to optimize away regular arguments, but not the static variables.

[Nils Minor]

Hi Ole,

sorry for that silly answer, yes i did not understand your answer in a correct way, but no i got it. I have done what you told me and found that an error come when using app_timer.

I use app timer for my button detection and start and stop the Timer by detecting rising or falling pins with gpiote. And it works but no i found that sometimes (not every time) an error occured by starting or stopping one timer. It is the error NRF_NRF_ERROR_NO_MEM ///< No Memory for operation. How is that possible?

I use nearly 18 Timer (not at same Time) but i also set #define APP_TIMER_MAX_TIMERS 23
#define APP_TIMER_OP_QUEUE_SIZE 23

Could that be a reason for my error?

Thank you, Nils

[Bastiaan]

If you look at the implementation of app_timer, you can see that all operations are queued and then handled from a software interrupt. If you do multiple calls to app_timer_* functions from a higher level interrupt, operations will need to be queued, and APP_TIMER_OP_QUEUE_SIZE sets the size of this queue. Take a look at this question for a better explanation of this parameter: https://devzone.nordicsemi.com/index.php/how-big-should-app_timer_op_queue_size-be

You will therefore either have to reduce the number of timer operations you do from higher-order interrupts, or move to using the scheduler, so that all operations happen from main context.