BLE Mesh Sensor Example

[Terry2]

I am attempting to get a BLE mesh network running using the BLE mesh sensor examples. I have one nRF52840 board and multiple Fanstel EVM-BC833 nRF52833 based boards. I have tried running both client and server examples on both boards with similar results so I must have a configuration issue. When I run the server example on the nRF52840 board and go through the provisioning the board, it reboots due to an MPU fault (see below). When I run the same example on the nRF52833 Fanstel board it continuously reboots (see below). I first load the S140 softdevice image using the programmer and then I use VS Code to program the example. I have not modified the board configuration for the nRF52840 and have created a board configuration for the Fanstel EVM using the nRF52833 eval board configuration as a template.

nRF52840DK Mesh Sensor Server Example output:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
Initializing...
Bluetooth initialized
Temperature sensor (temp@4000c000) initiated
Mesh initialized
[00:00:00.013,641] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:00.013,702] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:00.013,702] <inf> fs_nvs: data wra: 0, 0
[00:00:00.013,885] <inf> sdc_hci_driver: SoftDevice Controller build revision:
6d 90 41 2a 38 e8 ad 17 29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
1f 85 d8 e1 |....
[00:00:00.017,730] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:02:47.075,958] <inf> bt_mesh_main: Primary Element: 0x000f
[00:02:47.082,946] <err> os: ***** MPU FAULT *****
[00:02:47.082,977] <err> os: Stacking error (context area might be not valid)
[00:02:47.083,007] <err> os: Data Access Violation
[00:02:47.083,007] <err> os: MMFAR Address: 0x20007adc
[00:02:47.083,038] <err> os: r0/a1: 0x00000000 r1/a2: 0x00000000 r2/a3: 0x00000000
[00:02:47.083,038] <err> os: r3/a4: 0x00000000 r12/ip: 0x00000000 r14/lr: 0x00000000
[00:02:47.083,068] <err> os: xpsr: 0x81000000
[00:02:47.083,068] <err> os: Faulting instruction address (r15/pc): 0x00000b2c
[00:02:47.083,129] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:02:47.083,160] <err> os: Current thread: 0x20002ab0 (BT RX)
�*** Booting Zephyr OS build v3.2.99-ncs1 ***ng system
Initializing...
Bluetooth initialized
Temperature sensor (temp@4000c000) initiated
Mesh initialized

Fanstel EVM-BC833 Mesh Sensor Server Example output:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
Initializing...
[00:00:00.012,939] <err> os: ***** HARD FAULT *****
[00:00:00.012,969] <err> os: Fault escalation (see below)
[00:00:00.012,969] <err> os: ***** MPU FAULT *****
[00:00:00.013,000] <err> os: Stacking error (context area might be not valid)
[00:00:00.013,000] <err> os: Data Access Violation
[00:00:00.013,031] <err> os: MMFAR Address: 0x200083f0
[00:00:00.013,031] <err> os: r0/a1: 0x27d933dd r1/a2: 0x4d6433f5 r2/a3: 0x7c3ae4a7
[00:00:00.013,061] <err> os: r3/a4: 0x1039b650 r12/ip: 0xc06ddfea r14/lr: 0xfa0ee9cf
[00:00:00.013,061] <err> os: xpsr: 0x61000000
[00:00:00.013,092] <err> os: Faulting instruction address (r15/pc): 0x00003334
[00:00:00.013,122] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.013,183] <err> os: Current thread: 0x200033b8 (main)
[00:00:01.372,161] <err> fatal_error: Resetting system
*** Booting Zephyr OS build v3.2.99-ncs1 ***
Initializing...

[Hieu]

Hi Terry2,

It looks like you are building with debug options enabled. With that, the stack use will be higher than what is being set in prj.conf.

I could reproduce your exact issue when I build with debug options. I tried to double the stack size and the sample now works.

Please try the following Kconfig when you build that sample with debug options:

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4300

This was not necessary this time, but another stack that usually has problem when building with debug options is the main stack. That is configured by CONFIG_MAIN_STACK_SIZE.

Please watch out for any unexpected behavior when testing application built with debug options. There is also an issue in the BT stack size tracked here. It affects NCS v2.1.x and v2.2.0 to my knowledge. A solution has been added to the Zephyr upstream in this PR, but I am not certain if it has been fixed in v2.3.0 yet. I will get back to you regarding that soon.

Hieu

[Hieu]

Hi Terry2,

Just follow up on the fix that I mentioned in my last reply. It seems that it is not in NCS v2.3.0 or NCS latest development downstream yet.

It looks like the fix is not dependent on anything, so if you encounter a problem with Bluetooth behavior while build with debug options, you could try cherry picking the commit to your current NCS setup.

Hieu