hi Gaurav,

You might want to take a look at the KBA here.

Thanks

Hi all,

Is there an offline package for blemesh SDK v1.4? I need sdk v1.4 to generate the .gbl file that used for ota.

I tried to update blemesh sdk but failed.

Thanks!

hi KristinaP,

There is only function "RAILCb_AssertFailed" declaration in the header file by default.

Thanks

hi Carlton,

I tried to replicate the issue with the latest SDK (v1.4.0), however, didn't encounter the similar issue as you described. 
For your case, the Light node has received the request from Switch, could you dive into the function "mesh_lib_generic_server_event_handler" and check why the callback function "onoff_request" or "lightness_request" not be triggered?

Thanks
Cheng

hi Carlton,

1. 
-> I will try to reproduce it and get back to you later.

2.
-> The features Bitmask field in the DCD.c indicates the capabilities of the node, and you can set the relay state as disabled/enabled by using the "cmd_mesh_prov_relay_set" command.

3.
-> Not exactly, this command used to delete the application key indicated by the appkey_index parameter on a node.
-> For removing the node, you can perfrom a factory reset on the node side (can send the reset request from the provisioner by using the "cmd_mesh_prov_reset_node") to remove network keys, application keys, all publish and subscription settings etc, and delete node information from Provisioner database by using the command "cmd_mesh_prov_ddb_delete" on the embedded provisioner side.
Take a look at the discussion here.

4.
-> No need. If need to relay/forward mesh message between GATT and advertising bearers, the proxy feature shoud be enabled.

Thanks
Cheng

hi Jae-Won,

That's the "evt_mesh_health_server_attention" event, and should has no much relation with "gecko_cmd_mesh_test_set_local_config" calling.

Thanks

hi Valentin,

Yes, the gpiointerrupt.c should be involved in your project, and include the header file to avoid the warning. 

Did you enable other peripherals interrupt, however, didn't implement the ISR ? Please check the NVICABRx register to get the interrupt active bit.

Thanks

hi Jae-Won,

Similar as BLE, you can just drop the connection from the devices not the certain one. The discussion in the thread below might help.
https://www.silabs.com/community/wireless/bluetooth/forum.topic.0.15.html/bgm_single_devicepa-fUPj

Thanks

hi Xu,

That's much clear to me now.
I suspect that the SPI flash access in your firmware caused some timing issue, and the connection was broken. And the "reason" parameter of the "evt_le_connection_closed" event will show the reason.
Just now, I did a test with the BGM13P radio board, access the SPI flash with 1s interval, however, didn't encounter the similar symptom as yours.

Could you upload the simplest test code that can reproduce the issue with the BGM13P radio board (BRD4306A) ?

  MX25_SE(0x0000);
  MX25_PP(0x0000,flash_write_buffer,10);
  MX25_READ(0x0000,flash_read_buffer,10);

Thanks

hi Xu,

That's much clear to me now.
I suspect that the SPI flash access in your firmware caused some timing issue, and the connection was broken. And the "reason" parameter of the "evt_le_connection_closed" event will show the reason.
Just now, I did a test with the BGM13P radio board, access the SPI flash with 1s interval, however, didn't encounter the similar symptom as yours.

Could you upload the simplest test code that can reproduce the issue with the BGM13P radio board ?

  MX25_SE(0x0000);
  MX25_PP(0x0000,flash_write_buffer,10);
  MX25_READ(0x0000,flash_read_buffer,10);

Thanks