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

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

[Nils Minor]

Hi,

so i still have trouble with getting the DEADBEEF Error from the Softdice and don't know how i should going on. Sometimes when i stop debugging one libary open and close in a few seconds. i have made a picture, what does this mean?

best regards Nils

[Ole Morten]

This clearly shows that the CPU is in the HardFault Handler, and will occur if you either

• try to use to a protected peripheral (for instance writing to its registers, see the SoftDevice Specification for this list), or
• call a softdevice API function from an interrupt with priority 0 (see the appendix of the Reference Manual for an explanation)

Edit: A few additional things that might cause a HardFault:

• Accessing illegal addresses as RAM (for instance writing to address 0 or dereferencing a NULL pointer).
• Doing unaligned access (i.e. trying to set a value in RAM on a variable that is not located at a word-aligned address).

Using the latest softdevice, you will get a backtrace in Keil when you hit a HardFault, allowing you to see where the HardFault occured, so that is often a good way to find it. Remember to also upgrade the header files when replacing a softdevice.

[Nils Minor]

Hi Ole,

thank you for your reply. I will look for, if i do this but i can not imagine where i should do something like this.

How is it possible to write to a protected peripharal. I don't write to the flash or something like that.

Could it be possible that i have to configure the RAM at the beginning, becouse i don't do something like that.