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,

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.