Attachments (0)
Nordic Case Info
  • Case ID: 233844
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hard fault in ipc_trace_handle (proprietary Nordic library)

jbrzozoski

My application just hit the following fault randomly:

Fullscreen
1
2
3
4
5
6
7
8
9
10
Exception occurred in Secure State
***** HARD FAULT *****
Fault escalation (see below)
***** BUS FAULT *****
Precise data bus error
BFAR Address: 0x50008120
***** Hardware exception *****
Current thread ID = 0x20028dac (sysworkq)
Faulting instruction address = 0x319fe
Fatal fault in ISR! Spinning...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I tracked back in the map file and that is inside the Nordic NRFX library in ipc_trace_handle, so I have no source code to help me decode what I might be doing wrong.

Specifically in my linking, ipc_trace_handle starts at 0x3180c, so that is 0x1f2 bytes after the entry.  Here's a snippet for reference from the listing file:

Fullscreen
1
2
3
4
5
6
7
319f8: b109 cbz r1, 319fe <ipc_trace_handle+0x1f2>
319fa: 2100 movs r1, #0
319fc: 7011 strb r1, [r2, #0]
319fe: 68a5 ldr r5, [r4, #8]
31a00: 2d00 cmp r5, #0
31a02: d039 beq.n 31a78 <ipc_trace_handle+0x26c>
31a04: f04f 0c00 mov.w ip, #0
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Please, if someone from Nordic who has the source code for NRFX could help me understand what is being referenced in that area and give me a hint what might be wrong, I would really appreciate it.

Parents
  • 0

    Hi,

    Try to implement these functions in your main application (for instance in main.c):

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    void bsd_recoverable_error_handler(uint32_t error)
    {
    printf("Err: %lu\n", (unsigned long)error);
    }
    void bsd_irrecoverable_error_handler(uint32_t error)
    {
    printf("Irrecoverable: %lu\n", (unsigned long)error);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    And check if they are triggered before you get the HARD FAULT? I would like to know what the error parameter is set to.

  • 0 in reply to EvenFL

    I already have the error handlers implemented, but have them report via LOG_ERR instead of printk.  And (unfortunately) I run with deferred logging instead of immediate logging, so they might have been triggered but the hard fault went off before the logging thread had a chance to process/display them,

    I'll stick a log_panic() in those handlers to force it into immediate mode on failures...  However, I can't reproduce this fault reliably. It may be a while before I get anything.

    Why do you think a BSD error is likely to be related to a fault in the IPC handler?

  • 0 in reply to jbrzozoski

    I know that the ipc trace handler is in a code path that may trigger any of these handler if an error is detected as it's used in that parts of the BSD library. It may be that must run in a debug session and break inside this functions to be sure to capture the error code

    The 0x50008120 address is pointing the first UARTE instance on this devices, so I guesstimate that something is trying to print something on your console. However I am not sure why it fails, maybe because it's trying to access a non-secure peripheral using the secure peripheral address.

Reply
  • 0 in reply to jbrzozoski

    I know that the ipc trace handler is in a code path that may trigger any of these handler if an error is detected as it's used in that parts of the BSD library. It may be that must run in a debug session and break inside this functions to be sure to capture the error code

    The 0x50008120 address is pointing the first UARTE instance on this devices, so I guesstimate that something is trying to print something on your console. However I am not sure why it fails, maybe because it's trying to access a non-secure peripheral using the secure peripheral address.

Children
  • 0 in reply to EvenFL

    My application is compiled in NS mode with UARTE1 setup as NS, so nothing should be writing to the secure address.  That's an interesting bit of insight I missed.  Thank you.

    If the failure is related to the UARTE, then any printk or UART logging may not work.   Thankfully, I just got the RTT logging back-end working!  So a LOG_ERR in immediate mode should at least produce something through there.

    I haven't hit this error in the past week, though, so it's just a waiting game at this point...

  • 0 in reply to jbrzozoski

    Have you had any progress with the issue?

    You can also try to capture a trace using the Trace Collector in the nRF Connect Desktop

    www.nordicsemi.com/.../nRF-Connect-for-desktop

  • 0 in reply to EvenFL

    Haven't hit this one again since last week.  I've still got some extra debug code in place to hopefully provide more useful info if it happens again, but I can't reproduce it at this point and I'm focusing on other things.

Terms of service