• State Not Answered
  • Replies 9 replies
  • Subscribers 63 subscribers
  • Views 5977 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101006
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
Related