DEADBEEF in all registers

[evanperrygrove]

I have a device using nRF52840 with SDK 15.2.0 and S140 6.0.0. It has failed with some kind of error. All core registers (including PC, LR) contain DEADBEEF. PRIMASK = 0xef, BASEPRI=0xbe, CONTROL=0xde, so those are filled with DEADBEEF too. Could the softdevice cause something like this? I have not identified anywhere in my code where such behavior is possible.

[Susheel Nuguru]

Hi Evan,

DEADBEEF kind of seems like a manual insertion of error code, so I am guessing that this is not a hardfault.
You should be able to give us more context of the error. If you start your program in the debug mode starting the debugger, then you should be able to set breakpoints in the components\libraries\util\app_error_weak.c , components\libraries\hardfault\nrf52\handler and components\libraries\util\app_error.c to stop the flow and look at the function call stack to get more context on this error. Without knowing the context, it is not possible for us to know the source of this error.
Also there are a lot of related issues to DEADBEEF in the devzone, a quick search showed this result. Please check if one of them is relevant for you if you do not want to try the debugger breakpoint option first.

[evanperrygrove]

Upon further investigation, it seems like the "DEADBEEF in all registers" incident may be SES's way of indicating that it failed to communicate with the target device. I was, however, able to get a partial stack trace out of the device this time:

Address	PC
2003FCF0	0x1507E
2003FCD0	0x00978

[Susheel Nuguru]

I do not know what to make out with those addresses. What happens at that RAM and PC address and why is there more than one PC value? are you getting this error at different PC locations in different runs?

SES does not communicate to us in any way by filling the registers by 0XDEADBEEF. It has to be the firmware that is manually inserting this- Are you compiling your application with DEBUG flag set? Also compile it with NRF_LOG_ENABLED with RTT/UART backend . All asserts should have a good chance to be able to log something to the RTT/Serial with the detail information of PC, file number and line number if this is the applicaiton specific error or some code if this is the softdevice fault. Look more into components\libraries\util\app_error_handler_gcc.c

If you are not able to get any info from that then help us reproduce the error  by sharing your whole project so that we can try to debug it for you. I can make this case private for you so that you can share your project confidentially. 

[evanperrygrove]

> I do not know what to make out with those addresses. What happens at that RAM and PC address and why is there more than one PC value?

I don't know. Those PC addresses are in the S140 SoftDevice.

>why is there more than one PC value?

This is what I was able to recover from the stack trace. Because SES (and Ozone) don't have debugging info for the SoftDevice, this is all the data they show. The RAM addresses are just locations of PC values in the stack.

[Susheel Nuguru]

If this is a Softdevice assert. then the hardfault from softdevice should be forwarded to the application and you should be able to get the debug log from that application assert handler. Are you running your application with DEBUG flag and compile optimizations disabled?

I need a single PC address that is the cause of the hardfault to be able to investigate this more. If you cannot extract that info, then you should help me reproduce it on my end, so that i can attempt to extract that info.