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

[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.

[Guest]

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.