hi Bilal,

As you've raised a technical support case, I will follow up and get back to you later.

Thanks

hi Tung,

That's something defined in the stack, normally user don't need to modify them.

Thanks

hi HSonm,

Please see the KBA below for how to generate the image for production with debug lock enable, and encryption key attached.
https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/12/28/building_firmwareim-1OPr

For series 2 devices, lock the debug access is different with the series 1, debug access to the series 2 device processor can be closed by issuing commands to the Secure Element, either from a debugger over DCI or through the mailbox interface. With the default properties of the debug lock set, the device can be locked using the "Apply Lock" command. Please see the Table 5.5 of AN1190 for more information about the mailbox API.

Thanks

I just did a similar test with two BGX13P evaluation kit, and didn't encounter any problem while switching between the STREAM and COMMAND mode.

hi Behrooz,

Are you using the latest firmware v1.2.2376.1 (use the command ver to get the firmware version information) for the test ? And can you reproduce the issue with BGX+Phone combination ?

hi Todor,

Not sure how did you implement the NCP host project, I just take the ncp-host example in BLE SDK as starting point, and add the Bluetooth mesh BGAPI support to that project. The NCP host can initialize the Thunderboard BG22 which has ncp-btmesh-empty-target demo image programmed as a mesh node correctly.

The Bluetooth stack requires at least a 1.5 kB call stack to be reserved from RAM. Application developers must allocate RAM for the application call stack on top of the 1.5 kB required by the stack. By default, the call stack size if 2kB, the local variables are also stored on the stack, so you need to enlarge the stack size to meet your requirement, or define the array as global variable.

Please see "7.3.4 Call Stack" of UG136 for how to override the default setting.