• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 68 subscribers
  • Views 8817 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 283361
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bus Fault - Precise Data bus Error

Sriharsha Desai

Hi All,

We are using NCS v1.7.1 on our custom designed nRF52840 board. We have a touch screen interfaced with I2C to our device. There is one more controller connected on the same I2C bus, I will send commands to the controller via I2C to perform some operations. For UI I am using lvgl.

While I am performing some operations on the touch screen I am getting the following error given below. What does it mean? Why I am getting Bus Fault?

00> [00:00:35.213,104] <err> os: ***** BUS FAULT *****
00> [00:00:35.213,104] <err> os: Precise data bus error
00> [00:00:35.213,134] <err> os: BFAR Address: 0x12b008b[0m
00> [00:00:35.213,134] <err> os: r0/a1: 0x012b0077 r1/a2: 0x00000000 r2/a3: 0x00000077
00> [00:00:35.213,134] <err> os: r3/a4: 0x20006cfc r12/ip: 0x00000014 r14/lr: 0x0004934b
00> [00:00:35.213,134] <err> os: xpsr: 0x61000000
00> [00:00:35.213,134] <err> os: Faulting instruction address (r15/pc): 0x00049350
00> [00:00:35.213,165] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:35.213,165] <err> os: Current thread: 0x20002238 (unknown)
00> [00:00:35.491,088] <err> fatal_error: Resetting system

Any help on this.

Parents
  • +1

    Hello,

    Bus faults are a bit tricky debug, but I suspect that this is caused by a bad pointer somewhere. 

    You probably have gcc installed somewhere on your computer (in my case it is located under C:/Program files(x86)/GNU Tools ARM Embedded\9 2019-q4-major/

    Inside there, there is a tool found in bin/ called arm-none-eabi-addr2line.exe Add the path to this folder to your environment variables. We will use it later.

    Now, if you have recompiled your project since you posted this log, please check what the log says again. Some addresses may have changed.

    Faulting instruction address (r15/pc): 0x00049350

    Check what address this line is pointing to. If it is still the same address, then open a cmd window in your build folder, and use the following command:

    arm-none-eabi-addr2line -e _build/zephyr/zephyr.elf 0x49350

    This will give you a file name and a line number.

    You can also check addr2line on the address in your link register (LR/R14):

    arm-none-eabi-addr2line -e _build/zephyr/zephyr.elf 0x0004934b

    What you should see is that your link register will point to one function that calls the function in your r15/pc. 

    What functions do you find here? Do you see anything that could cause the application to fault? A bad pointer? A callback function that hasn't been set properly? Something trying to access a pointer that is out of bands?

    Perhaps you can add some logging around that place, and see whether you get some log info before the crash?

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    Bus faults are a bit tricky debug, but I suspect that this is caused by a bad pointer somewhere. 

    You probably have gcc installed somewhere on your computer (in my case it is located under C:/Program files(x86)/GNU Tools ARM Embedded\9 2019-q4-major/

    Inside there, there is a tool found in bin/ called arm-none-eabi-addr2line.exe Add the path to this folder to your environment variables. We will use it later.

    Now, if you have recompiled your project since you posted this log, please check what the log says again. Some addresses may have changed.

    Faulting instruction address (r15/pc): 0x00049350

    Check what address this line is pointing to. If it is still the same address, then open a cmd window in your build folder, and use the following command:

    arm-none-eabi-addr2line -e _build/zephyr/zephyr.elf 0x49350

    This will give you a file name and a line number.

    You can also check addr2line on the address in your link register (LR/R14):

    arm-none-eabi-addr2line -e _build/zephyr/zephyr.elf 0x0004934b

    What you should see is that your link register will point to one function that calls the function in your r15/pc. 

    What functions do you find here? Do you see anything that could cause the application to fault? A bad pointer? A callback function that hasn't been set properly? Something trying to access a pointer that is out of bands?

    Perhaps you can add some logging around that place, and see whether you get some log info before the crash?

    Best regards,

    Edvin

Children
Related