LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Tue, 04 May 2021 10:21:01 GMT

Thanks for the help.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Jared — Tue, 04 May 2021 03:40:50 GMT

FYI opened a bug about this: https://github.com/zephyrproject-rtos/zephyr/issues/34794

I think previously if INT2 was not defined, it would fail gracefully. Something in the device tree API has changed which causes Zephyr to fault.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Fri, 16 Apr 2021 08:35:24 GMT

Yes, that's how you do it. Check how it's done here: https://github.com/nrfconnect/sdk-zephyr/blob/v2.4.99-ncs2/boards/arm/nrf9160_innblue21/nrf9160_innblue21_common.dts#L98.

It is often helpful to search trough NCS/Zephyr to figure out how stuff are done, either by using the search tools of an IDE, or the git grep command. Now I simply typed in git grep irq-gpios in the Zephyr repo and found the above.

Best regards,

Simon

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Wed, 14 Apr 2021 16:33:19 GMT

How do you specify the 2nd interrupt pin? By adding a comma after the first irq-gpios?

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Wed, 14 Apr 2021 16:31:09 GMT

It seems like you got help with this here: https://devzone.nordicsemi.com/f/nordic-q-a/73838/lis2dh-int1-triggers-on-nrf9160. Should we close this case?

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Sun, 11 Apr 2021 19:29:04 GMT

It turns out INT1 AND INT2 need to be specified in the .dts board file. How do you specify a second interrupt?

lis2dh@18 {
compatible = "st,lis2dh";
reg = <0x18>;
irq-gpios = <&gpio0 12 0>; // GPIO_ACTIVE_HIGH>;
label = "LIS2DH";
};

Additionally, the Zephyr driver does not support motion sensing on INT1. After making some changes to the driver code, this still isn't working. I'll open another ticket in regards to this issue.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Mon, 29 Mar 2021 17:00:05 GMT

It would be useful to see what's happening on some higher abstraction layers (string.c:147 is at the bottom of the stack). Try to do some debugging (put a breakpoint at string.c:147) or simply add some logs (printk()) in the source files located in zephyr\drivers\sensor\lis2dh (put logs in the init functions, which runs before main) to figure out where it fails.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Mon, 29 Mar 2021 14:09:19 GMT

$ /c/Users/Paul/ncs/v1.5.0/toolchain/opt/bin/arm-none-eabi-addr2line -e zephyr.elf 0x00013052
C:/Users/Paul/ncs/v1.5.0/zephyr/lib/libc/minimal/source/string/string.c:147

devzone.nordicsemi.com/.../8877.zephyr.dts

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Mon, 29 Mar 2021 13:51:24 GMT

Do the following:

cd <sample>/<build folder>/zephyr
addr2line -e zephyr.elf 0x00013052

I guess:

<sample>=<ncs locatiopn>\zephyr\samples\sensor\lis2dh
<build folder>=build

Could you also show me how you have configured LIS2DH and the interrupt pin in the device tree. Upload the file <sample>/<build folder>/zephyr/zephyr.dts.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Mon, 29 Mar 2021 13:13:13 GMT

I made the following change:

CONFIG_MAIN_STACK_SIZE=8192

I have the debugger stopping on the first line of main.c but it dies before then.

I was able to get more data this time:

[00:02:53.252,136] [1;31m<err> os: Exception occurred in Secure State[0m
[00:02:53.259,063] [1;31m<err> os: ***** HARD FAULT *****[0m
[00:02:53.264,862] [1;31m<err> os: Fault escalation (see below)[0m
[00:02:53.271,423] [1;31m<err> os: ***** BUS FAULT *****[0m
[00:02:53.277,160] [1;31m<err> os: Precise data bus error[0m
[00:02:53.283,172] [1;31m<err> os: BFAR Address: 0x50008158[0m
[00:02:53.289,367] [1;31m<err> os: r0/a1: 0x00000000 r1/a2: 0x00013ff2 r2/a3: 0x00000000[0m
[00:02:53.298,492] [1;31m<err> os: r3/a4: 0xffffffff r12/ip: 0x0000000a r14/lr: 0x000112b3[0m
[00:02:53.307,617] [1;31m<err> os: xpsr: 0x21000000[0m
[00:02:53.313,079] [1;31m<err> os: Faulting instruction address (r15/pc): 0x00013052[0m
[00:02:53.321,380] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0[0m
[00:02:53.329,559] [1;31m<err> os: Current thread: 0x20010178 (unknown)[0m
[00:02:53.356,689] [1;31m<err> os: Halting system[0m
[00:00:00.001,953] [0m<inf> lis2dh: int1 on GPIO_0.06

Debugger shows it stopping here:

SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_exc_spurious)

mrs r0, MSP

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Mon, 29 Mar 2021 09:44:41 GMT

Is that all the log you got? Did you not get "Faulting instruction address (r15/pc): <faulting address>"? That should tell you exactly what line of code that is failing, by using addr2line -e zephyr.elf <faulting address>.

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

NautDesigner — Sun, 28 Mar 2021 20:45:26 GMT

Turning on those settings I get the following:

[00:00:00.203,613] [0m<inf> lis2dh: int1 on GPIO_0.06[0m
[00:00:00.204,071] [1;31m<err> os: Exception occurred in Secure State[0m
[00:00:00.204,528] [1;31m<err> os: ***** HARD FAULT *****[0m
[00:00:00.204,925] [1;31m<err> os: Fault escalation (see below)[0m
[00:00:00.205,383] [1;31m<err> os: ***** BUS FAULT *****[0m
[00:00:00.205,780] [1;31m<err> os: Precise data bus error[0m
[00:00:00.206,207] [1;31m<err> os: BFAR Address: 0x50008158[0m
[00:00:00.206,665] [1;31m<err> os: r0/a1: 0x00000000 r1/a2: 0x000485ac r2/a3: 0x00000000[0m
[00:00:00.207,275] [1;31m<err> os: r3/a4: 0x00000001 r12/ip: 0x0000a000 r14/lr: 0x0003620d[0m
[00:00:00.207,916] [1;31m<err> os: xpsr: 0x21000000[0m
[00:00:00.208,343] [1;31m<err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000[0m
[00:00:00.209,106] [1;31m<err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000[0m
[00:00:00.209,838] [1;31m<err> os: s[ 8]: 0x00000000[00:00:00.203,338] [0m<inf> lis2dh: int1 on GPIO_0.06[0m

RE: LIS2DH Trigger Giving z_arm_mpu_fault()LIS2

Simon — Sun, 28 Mar 2021 19:58:34 GMT

Could you try set CONFIG_LOG=y, and CONFIG_RESET_ON_FATAL_ERROR=n. Then check the log to see the line that caused the issue (use addr2line).

The issue may be due to a stack overflow, check out the ticket Stack Overflow for more information how to resolve the issue then.

Best regards,

Simon