Hi, I've created new PR https://github.com/zephyrproject-rtos/zephyr/pull/8101. It is basically modified version of samples/bluetooth/mesh as well as inspired from samples/boards/nrf52/mesh/onoff-app.

#bluetoothmesh

Hi, I commented line no. 3318 of subsys/bluetooth/host/hci_core.c i.e. // BT_ASSERT(buf); And after that everything is working perfectly normal. Thanks !!

#bluetoothmesh

Hi Vikrant, OK in that case I will try to run the onoff mesh app to see if I can reproduce at all. Thanks for the help in debugging this. Carles

#bluetoothmesh

Hi Carles, I tried it with samples/boards/nrf52/mesh/onoff-app ....Here too, I faced kernel OOPS. But in that case, occurrence frequency was very low. I'm facing all these issues after 1.12.0-rc2 upda

#bluetoothmesh

Hi Vikrant, Can you please try to reproduce this with standard samples present in the Zephyr tree? Thanks, Carles

#bluetoothmesh

Hi, These are today's OOPS & Faults root@vikrant-iMac:/home/vikrant/projects/bluez/mesh# /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e /home/vikran

#bluetoothmesh

What board is this on? Check for stack overflow, on devices with NXP MPUs these get reported as bus faults. Andrew

#bluetoothmesh

This is starting to look more and more like a memory corruption or kernel issue at this point. I cannot reproduce this easily by running our standard Bluetooth samples, so I am a bit at a loss here. I

#bluetoothmesh

Hi to all, Suddenly get this non-stoppable FAULT ***** BUS FAULT ***** Executing thread ID (thread): 0x20000220 Faulting instruction address: 0x1c9a4 Precise data bus error Address: 0xe5f7ffbe Fatal f

#bluetoothmesh

Hi Carles, Now get these FAULT/OOPS, ***** MPU FAULT ***** Executing thread ID (thread): 0x20001eb0 Faulting instruction address: 0x200006b8 Instruction Access Violation Fatal fault in thread 0x20001e

#bluetoothmesh

Hi Vikrant, Thanks for looking into this. It seems like we do not get a buffer back from the command tx queue: https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/host/hci_core.c

#bluetoothmesh

Hi Carles, Input -> /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e /home/vikrant/projects/zephyr/zephyr/samples/bluetooth/mesh2/build/zephyr/zephyr.

#bluetoothmesh

If you are using the Zephyr SDK: path-to-zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e zephyr.elf <addr> Carles

#bluetoothmesh

Hi Carles, I will but don't know, how to do that ?

#bluetoothmesh

Hi Vikrant, Can you please run addr2line with this address present in the error log: 0x5222? Thanks, Carles

#bluetoothmesh

Hello World !! Today after upgrading to v1.12.0-rc2, I'm getting following error while playing with sample code which is inspired from sample/bluetooth/mesh [bt] [ERR] hci_tx_thread: assert: 'err == 0

#bluetoothmesh

Hi, Assume 1) a company don't wanna go with any cloud service to store & upgrade #BluetoothMesh .json file for his products. 2) And no #OOB authentication during provisioning 3) On other side, user pr

#bluetoothmesh

Hi Vikrant, Mesh will work with any settings backend (currently FCB and NFFS, and in the future with NVS). Johan

#fcb #nvs #bluetoothmesh

Hi Andrzej, Is #BluetoothMesh stack completely independent from persistence storage mechanism used by #SettingLayer ? If yes, then only it will possible. 😃 Thank You !!

#fcb #nvs #bluetoothmesh

Hi. I Think it will be possible – (but can’t be sure). At last Jehudi Maes (the NVS author) is considering right now ho to provide nvs-back-end for the setting (I’m in touch with him). Andrzej

#fcb #nvs #bluetoothmesh