This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

bus_fault

I am generating a bus fault with the code

static struct cloud_channel_data *ccd=0;
int i = ccd->type;

I wish to run the program under SEGGER debugger or any other debugger you recommend, and locate where the bus fault occurred. However, when I trace the code path in fault.c, in function fault_handle(), the type of the fault that occurs is not bus fault, but rather secure_fault(). The board will reboot and never give me the chance to get information on the bus fault. Please help show me the debugging techniques that will overcome this limitation. Thank you very much. FYI, I do this in v1.3.0 asset_tracker code near the start of main(). 

Parents
  • Hi,

     

    We are unfortunately aware of this issue, and we are actively looking into how to ease the fault debugging scenario.

    Could you try adding the configs listed in this PR to the asset_tracker/spm.conf file?

    https://github.com/nrfconnect/sdk-nrf/pull/2550/files

     

    Kind regards,

    Håkon

  • Thank you, Hakon. Using your recommendation, I seem to have a workable procedure: I run the program and get something like this when the bus error occurs:

    [00:00:05.942,108] <err> os: Exception occurred in Secure State
    [00:00:05.948,791] <err> os: ***** HARD FAULT *****
    [00:00:05.954,406] <err> os: Fault escalation (see below)
    [00:00:05.960,723] <err> os: ***** BUS FAULT *****
    [00:00:05.966,247] <err> os: Precise data bus error
    [00:00:05.972,045] <err> os: BFAR Address: 0x50008120
    [00:00:05.977,996] <err> os: r0/a1: 0x20020520 r1/a2: 0x00000000 r2/a3: 0x22400000
    [00:00:05.986,785] <err> os: r3/a4: 0x00000000 r12/ip: 0x0000090b r14/lr: 0x00020337
    [00:00:05.995,574] <err> os: xpsr: 0x41000000
    [00:00:06.000,854] <err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000
    [00:00:06.011,383] <err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000
    [00:00:06.021,911] <err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000
    [00:00:06.032,440] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
    [00:00:06.042,968] <err> os: fpscr: 0x93f7edc9
    [00:00:06.048,248] <err> os: Faulting instruction address (r15/pc): 0x000281a8
    [00:00:06.056,213] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
    [00:00:06.064,117] <err> os: Current thread: 0x200273a0 (unknown)
    [00:00:06.070,953] <err> asset_tracker: Running main.c error handler
    [00:00:06.078,033] <err> asset_tracker: Unknown error type: 3, code: 0

    I take the Faulting instruction address and search for it in build/zephyr/zephyr.lst. That gives me my answer.

    Is there any simplification that would show the C code line directly without having to look for it in the listing -- something like GDB might do? And if I used the Segger ES Debugger, it seemed like a bit more work for me to get to the same result as I show above. Anyway, what we have is certainly usable.

    Burt

Reply
  • Thank you, Hakon. Using your recommendation, I seem to have a workable procedure: I run the program and get something like this when the bus error occurs:

    [00:00:05.942,108] <err> os: Exception occurred in Secure State
    [00:00:05.948,791] <err> os: ***** HARD FAULT *****
    [00:00:05.954,406] <err> os: Fault escalation (see below)
    [00:00:05.960,723] <err> os: ***** BUS FAULT *****
    [00:00:05.966,247] <err> os: Precise data bus error
    [00:00:05.972,045] <err> os: BFAR Address: 0x50008120
    [00:00:05.977,996] <err> os: r0/a1: 0x20020520 r1/a2: 0x00000000 r2/a3: 0x22400000
    [00:00:05.986,785] <err> os: r3/a4: 0x00000000 r12/ip: 0x0000090b r14/lr: 0x00020337
    [00:00:05.995,574] <err> os: xpsr: 0x41000000
    [00:00:06.000,854] <err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000
    [00:00:06.011,383] <err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000
    [00:00:06.021,911] <err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000
    [00:00:06.032,440] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
    [00:00:06.042,968] <err> os: fpscr: 0x93f7edc9
    [00:00:06.048,248] <err> os: Faulting instruction address (r15/pc): 0x000281a8
    [00:00:06.056,213] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
    [00:00:06.064,117] <err> os: Current thread: 0x200273a0 (unknown)
    [00:00:06.070,953] <err> asset_tracker: Running main.c error handler
    [00:00:06.078,033] <err> asset_tracker: Unknown error type: 3, code: 0

    I take the Faulting instruction address and search for it in build/zephyr/zephyr.lst. That gives me my answer.

    Is there any simplification that would show the C code line directly without having to look for it in the listing -- something like GDB might do? And if I used the Segger ES Debugger, it seemed like a bit more work for me to get to the same result as I show above. Anyway, what we have is certainly usable.

    Burt

Children
  • Hi Burt,

     

    Burt said:
    Is there any simplification that would show the C code line directly without having to look for it in the listing -- something like GDB might do? And if I used the Segger ES Debugger, it seemed like a bit more work for me to get to the same result as I show above. Anyway, what we have is certainly usable.

    I got the addresses out on my UART terminal, as well as the stack trace while in debug mode. SES should be able to give you the stack trace atleast, but you'll still have to look at the register content when you faulted (frame: z_arm_fault()) to see where you came from.

    You can use gdb, as you mention, "list *0xaddr":

    (gdb) list *0x20184
    0x20184 is in main (../src/main.c:1747).
    1742
    1743    void main(void)
    1744    {
    1745            LOG_INF("Asset tracker started");
    1746            int * ptr = 0;
    1747            *ptr = 0xFFFFEEFE;
    1748            if (*ptr == 0)
    1749                    printk("Hi\n");
    1750            k_work_q_start(&application_work_q, application_stack_area,
    1751                           K_THREAD_STACK_SIZEOF(application_stack_area),

     

    Or, use arm-none-eabi-addr2line -e <my_elf_file> 0xADDR, which should give you the file and line number:

    C:\SDK\ncs\nrf\applications\asset_tracker\build>arm-none-eabi-addr2line.exe -e zephyr\zephyr.elf 0x20184
    C:\sdk\ncs\nrf\applications\asset_tracker\build/../src/main.c:1747

     

    Kind regards,

    Håkon

Related