• State Verified Answer
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 3919 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 236970
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Interpreting error messages

Tron

I get the following error message from my device 

àÓ FATAL: Exception occurred in Secure State
[10.2 10:01:52.062]FATAL: ***** HARD FAULT *****
[10.2 10:01:52.062]FATAL: Fault escalation (see below)
[10.2 10:01:52.062]FATAL: ***** BUS FAULT *****
[10.2 10:01:52.062]FATAL: Precise data bus error
[10.2 10:01:52.062]FATAL: BFAR Address: 0x50008120
[10.2 10:01:52.062]FATAL: r0/a1: 0x2002ff28 r1/a2: 0x00000000 r2/a3: 0x00000000
[10.2 10:01:52.062]FATAL: r3/a4: 0x0000000a r12/ip: 0x00000000 r14/lr: 0x0003dd33
[10.2 10:01:52.062]FATAL: xpsr: 0x61000000
[10.2 10:01:52.062]FATAL: s[0]: 0x00000000 s[1]: 0x00000000 s[2]: 0x00000000 s[3]: 0xffffffff
[10.2 10:01:52.062]
[10.2 10:01:52.062]FATAL: s[4]: 0xffffffff s[5]: 0xffffffff s[6]: 0x00000000 s[7]: 0xffffffff
[10.2 10:01:52.106]
[10.2 10:01:52.106]FATAL: s[8]: 0x00000000 s[9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000
[10.2 10:01:52.106]
[10.2 10:01:52.106]FATAL: s[12]: 0xffffffff s[13]: 0x264a6500 s[14]: 0x03e0d11c s[15]: 0x00000000
[10.2 10:01:52.106]
[10.2 10:01:52.106]FATAL: fpscr: 0x00000000
[10.2 10:01:52.106]
[10.2 10:01:52.106]FATAL: Faulting instruction address (r15/pc): 0x0004a3a4
[10.2 10:01:52.106]FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
[10.2 10:01:52.106]FATAL: Current thread: 0x20025318 (unknown)
[10.2 10:01:52.106][00:05:31.572,479] <err> at_cmd: Failed to send AT command (err:22)
[10.2 10:01:52.106]FATAL: Halting system

Which tools atre at my disposal to understand this error mesage?

Parents
  • +1

    Hi.

    I agree that Zephyr's (and by extension NCS's) hard fault messages can be hard to get useful information from.

    Usually, they are caused by some invalid memory access, due to a previously failed operation. Hopefully, your log also reports that original failure.

    In your case, starting at the bottom, we see that you get error code 22 (EINVAL, Invalid argument) from the at_cmd library.

    Then, Zephyr encounters a CPU exception, and prints the ID of the current thread. This is not much help in itself, but if you get the ID of all your threads at startup (using k_current_get), you would know which thread encountered the problem.

    You then get a bus fault. This is one of the possible hardware faults the CPU can get. You can read more about it in ARM's documentation. It also dumps the content of all the CPU registers and the stack frame. This might be of help, but often requires some reading of the disassembled project to be useful.

    You also get the BFAR address or the address that caused the bus fault. In this case: 0x50008120. Using the Product Specification, we see that the address is used by UARTE0_S. The S at the end means that it is the secure version of the peripheral. As the application is running as non-secure, it does not have access to this register.

    Hope this answers your question.

    Best regards,

    Didrik

Reply
  • +1

    Hi.

    I agree that Zephyr's (and by extension NCS's) hard fault messages can be hard to get useful information from.

    Usually, they are caused by some invalid memory access, due to a previously failed operation. Hopefully, your log also reports that original failure.

    In your case, starting at the bottom, we see that you get error code 22 (EINVAL, Invalid argument) from the at_cmd library.

    Then, Zephyr encounters a CPU exception, and prints the ID of the current thread. This is not much help in itself, but if you get the ID of all your threads at startup (using k_current_get), you would know which thread encountered the problem.

    You then get a bus fault. This is one of the possible hardware faults the CPU can get. You can read more about it in ARM's documentation. It also dumps the content of all the CPU registers and the stack frame. This might be of help, but often requires some reading of the disassembled project to be useful.

    You also get the BFAR address or the address that caused the bus fault. In this case: 0x50008120. Using the Product Specification, we see that the address is used by UARTE0_S. The S at the end means that it is the secure version of the peripheral. As the application is running as non-secure, it does not have access to this register.

    Hope this answers your question.

    Best regards,

    Didrik

Children
No Data
Related