DEADBEEF in my Code but from where?

RE: DEADBEEF in my Code but from where?

Nils Minor — Thu, 28 Nov 2013 17:32:15 GMT

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.

RE: DEADBEEF in my Code but from where?

Ole Morten — Thu, 28 Nov 2013 17:05:01 GMT

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.

RE: DEADBEEF in my Code but from where?

Nils Minor — Thu, 28 Nov 2013 16:58:24 GMT

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

RE: DEADBEEF in my Code but from where?

Bastiaan — Thu, 28 Nov 2013 12:13:33 GMT

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.

RE: DEADBEEF in my Code but from where?

Guest — Thu, 28 Nov 2013 12:13:33 GMT

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.

RE: DEADBEEF in my Code but from where?

Nils Minor — Thu, 28 Nov 2013 10:56:30 GMT

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

RE: DEADBEEF in my Code but from where?

Ole Morten — Wed, 27 Nov 2013 16:52:41 GMT

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.

RE: DEADBEEF in my Code but from where?

Nils Minor — Wed, 27 Nov 2013 16:47:12 GMT

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

RE: DEADBEEF in my Code but from where?

Ole Morten — Wed, 27 Nov 2013 16:35:09 GMT

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?