Zephyr Project Startup Hardfault using the Matter LightBulb example.

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Thu, 08 Feb 2024 19:17:58 GMT

I got the application running. I added the following to prj_no_dfu.conf (sanity modification)

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_LOW_SWING=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=n

This fixed part of the problem.
The other problem was due to a poorly attached 32Mhz crystal. Seems this causes a fault. Go figure.
I found this out by walking all the way back to the esb_ptx project , just to see if our radio worked at all, and immediately the program locked up waiting for the high frequency clock to start.

So, if you are having issues like mine, run a small test program to test your high frequency clock AND if you don't have crystal in your design remember to use an alternate low frequency source of K32SRC_RC.

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Wed, 07 Feb 2024 16:19:42 GMT

So I tried the zephyr beacon project. And that failed with the same kind of MPSL error:

Beacon started, advertising as F8:3D:7C:A6:ED:BE (random)
[00:00:00.007,537] <err> mpsl_init: MPSL ASSERT: 112, 2185
[00:00:00.007,537] <err> os: ***** HARD FAULT *****
[00:00:00.007,568] <err> os: Fault escalation (see below)
[00:00:00.007,568] <err> os: ARCH_EXCEPT with reason 3

[00:00:00.007,598] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x0
000000b
[00:00:00.007,598] <err> os: r3/a4: 0x20001138 r12/ip: 0x20000ae0 r14/lr: 0x0
000ae35
[00:00:00.007,629] <err> os: xpsr: 0x41000018
[00:00:00.007,629] <err> os: Faulting instruction address (r15/pc): 0x0000fbbc
[00:00:00.007,659] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:00.007,690] <err> os: Fault during interrupt handling

[00:00:00.007,720] <err> os: Current thread: 0x20001138 (unknown)
ø00:00:01.506,835] <err> fatal_error: Resetting system

I am guessing the ASSERT doesn't mean anything useful.
Next I will try a NON zephyr ble example.

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Wed, 07 Feb 2024 13:50:08 GMT

Are you able to successfully run other examples from the SDK on your board, such as the hello_world from Zephyr (to verify that your toolchain and debugger is functioning as it should), or any of the BLE applications (to verify that the rest of your hardware is functioning as expected)?

Just to be complete, I did run a zephyr blinky example. The SAME hex file ran properly on both our board AND the nrf52840-DK. It's a primitive program, so it that isn't much an example of similarity, other than the base zephyr kernel functioning. Still haven't tried a different radio program yet (though I would love to play with ESB again, I know it isn't the same).

Have you made your own board files for this board, and used this instead of the nRF52840 DK board files as the build target for the Matter lightbulb application?

I did create some board files specific to our board. Checking them again.

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Tue, 06 Feb 2024 19:52:53 GMT

OK , if 112 refers to the numbers in syscall_list.h then the failure is in K_TIMER_START()... i think??

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Tue, 06 Feb 2024 19:29:24 GMT

Ok, this took too much effort, but I connected the serial port and captured:
E: MPSL ASSERT: 112, 2185
E: ***** HARD FAULT *****
E: Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1: 0x00000003 r1/a2: 0x2000efe0 r2/a3: 0x2000efe0
E: r3/a4: 0x20016f88 r12/ip: 0x00000000 r14/lr: 0x0003115f
E: xpsr: 0x61000018
E: s[ 0]: 0x00000000 s[ 1]: 0x0000e349 s[ 2]: 0x00323131 s[ 3]: 0x00000000
E: s[ 4]: 0x00000000 s[ 5]: 0x0000be03 s[ 6]: 0x00000000 s[ 7]: 0x40008000
E: s[ 8]: 0x20000008 s[ 9]: 0xe000e000 s[10]: 0x00000100 s[11]: 0x0000d9ff
E: s[12]: 0x0004e8bd s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
E: fpscr: 0x00000000
E: Faulting instruction address (r15/pc): 0x0003116a
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x2000efe0 (idle)
E: Halting system

So MPSL ASSERT makes sense.

Can you help on what file 112, line 2185 equate to??

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Tue, 06 Feb 2024 18:32:40 GMT

NOPE THIS IS WRONG.

I think my issue is coming from this point in the code at ISR_DIRECT_PM() or just before it:

static void mpsl_radio_isr_wrapper(const void *args)
{
	ARG_UNUSED(args);

	MPSL_IRQ_RADIO_Handler();

	ISR_DIRECT_PM();
}

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Tue, 06 Feb 2024 18:03:40 GMT

No - I haven't tried any other BLE programs yet, but perhaps I should at this point.

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

AMarch — Tue, 06 Feb 2024 18:02:50 GMT

Originally, I was trying to get blinky to function on the board. I was having problems and then I found out I needed to set

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to get it to function. This is what led my initial question of if it is necessary to have the 32Khz crystal to make these things work at all. This took a minute to figure out until I tested the exact same .hex file on our board and the nrf52840-DK board (which I have because I wasn't going to think of doing this without an actual demo board in hand). Finally I realized that the difference was the crystal. After making the change to the .conf file, blinky worked find on our board.

I decided to take a big step and move to the matter-lightbulb example. The code executes and I can single step to a point. The downside, of course, is that this is an OS so I can't step through everything linearly.

I decided to buckle down and take some more detailed notes. I rebuilt the project and started it in oxygen again.
The fault happens reliably as HardFault exception at 0x0003116A.(yes very different from the fault address in the first post)
If I read this correctly, the Fault is being generated in this location, and looking at the map file it appears that this is m_assert_handle.
So apparently, I am hitting an MPSL assert for some reason. I haven't figured what causes this yet, but that should be next.

Currently my prj.conf (prj_no_dfu.conf) is

# Enable CHIP
CONFIG_CHIP=y
CONFIG_CHIP_PROJECT_CONFIG="src/chip_project_config.h"
# 32773 == 0x8005 (example lighting-app)
CONFIG_CHIP_DEVICE_PRODUCT_ID=32773
CONFIG_STD_CPP14=y

# Enable CHIP pairing automatically on application start.
CONFIG_CHIP_ENABLE_PAIRING_AUTOSTART=y

# Add support for LEDs and buttons on Nordic development kits
CONFIG_DK_LIBRARY=y
CONFIG_PWM=y

# Bluetooth Low Energy configuration
CONFIG_BT_DEVICE_NAME="MatterLight"

# Other settings
CONFIG_THREAD_NAME=y
CONFIG_MPU_STACK_GUARD=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_CHIP_LIB_SHELL=y

# Disable Matter OTA DFU
CONFIG_CHIP_OTA_REQUESTOR=n

# Disable QSPI NOR
CONFIG_CHIP_QSPI_NOR=n

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_LOW_SWING=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=n

CONFIG_SCHED_CPU_MASK=y
CONFIG_THREAD_ANALYZER=y

RE: Zephyr Project Startup Hardfault using the Matter LightBulb example.

Karl Ylvisaker — Tue, 06 Feb 2024 16:19:42 GMT

Hello,

[quote user=""]I had single stepped through most of the init function for the main class, so I know it is executing code.[/quote]

Does this hardfault trigger at a particular line of code during the initialization? If so, where?

[quote user=""]This board is simply the nrf52840, with the same LEDs and two of the buttons form the nrf52840-DK board.
We do not have the 32Khz crystal (which was a problem for me initially to get the code to start). Has anyone seen the code simply fail like this?[/quote]

Are you able to successfully run other examples from the SDK on your board, such as the hello_world from Zephyr (to verify that your toolchain and debugger is functioning as it should), or any of the BLE applications (to verify that the rest of your hardware is functioning as expected)?

[quote user=""]This board is simply the nrf52840, with the same LEDs and two of the buttons form the nrf52840-DK board. [/quote]

Have you made your own board files for this board, and used this instead of the nRF52840 DK board files as the build target for the Matter lightbulb application?

Best regards,
Karl