custom profile possible bug

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
ilnur_muham
Offline
Last seen:2 months 3 weeks ago
加入:2016-02-17 07:59
custom profile possible bug

I'm using custom profiles.

My device should send some data using indications.

First question, what is correct method to send indication on custom profiles? Should I use CUSTS2_VAL_NTF_REQ(with notification = false in custs_val_ntf_ind_req parameter structure) or CUSTS2_VAL_IND_REQ message?

If I use CUSTS2_VAL_IND_REQ I cannot send indications at all because when request is handled attmdb_get_value(cfg_hdl, &length, &cfg_val) return ATT_ERR_REQUEST_NOT_SUPPORTED = 0x06, but where is even no check for returned value.

If I use CUSTS2_VAL_NTF_REQ I can send indication but have something that looks like a bug.

如果在重新连接之后发生由超时引起的断开,我无法接收指示。
What do I see?
断开后,my task's state is still CUSTS2_BUSY, so I cannot send new indications.

sdk version 6.0.4.326, chip DA14586

Device:
MT_dialog
Offline
Last seen:2个月4周前
Staff
加入:2015-06-08 11:34
Hi ilnur_muham,

Hi ilnur_muham,

The proper way is to pass the CUSTS2_VAL_NTF_REQ with a notification set to false, the other message (CUSTS2_VAL_IND_REQ) is going to be ommited in next releases of the SDK and its obsolete (and not operational). The reason you get this result from the attmdb_get_values is because the SDK passes a wrong handle for the value to be updated. So the proper way is to use the CUSTS2_VAL_NTF_REQ and the notification in false.

Regarding the second issue that you have, the indications require a confirmation from central, so in order to send the next indication the previous one has to be confirmed, apparently since there is no communication (since there is a timeout), the device is still in busy state, waiting to get a confirmation from the client, but apparently it doesn't and stays in busy state, a quick workaround you can try is to set the task in IDLE state upon disconnection with the ke_state_set(task, CUSTS2_IDLE). As far as i can tell this can be a problem upon disconnections as you have mentioned, i informed the SDK team on this.

Thanks MT_dialog

ilnur_muham
Offline
Last seen:2 months 3 weeks ago
加入:2016-02-17 07:59
I just want to mention that

I just want to mention that second issue occurs with notifications too.

My current workaround which seems to be working for me is to add following lines to custs2_cleanup.

struct custs2_env_tag *custs2_env = (struct custs2_env_tag *)env->env;
if(custs2_env->operation != NULL)
{
ke_free(custs2_env->operation);
custs2_env->operation = NULL;
ke_state_set(prf_src_task_get(&(custs2_env-> prf_env),0),custs2_idle);
}

MT_dialog
Offline
Last seen:2个月4周前
Staff
加入:2015-06-08 11:34
Hi ilnur_muham,

Hi ilnur_muham,

I can see the issue that you are reporting regarding the indications, but i am not able to see what you are mentioning regarding the notifications, at least on the peripheral example, when the device is disconnected, you can connect again and the device is going to be able to send notifications again. What causes the issue as far as i can tell are indications only where the device in order for the profile to go back to IDLE state it should get a confirmation from the central device.

Thanks MT_dialog

mkelwood
Offline
Last seen:1 week 6 days ago
加入:2017-05-19 18:27
Is it still true that CUSTSx

Is it still true that CUSTSx_VAL_IND_REQ is deprecated as a way to send characteristic indications? I have implemented an indicated characteristic using this message on DA14585, SDK 6.0.6.427, and it seems to be working fine (i.e. it is "operational" contrary to the guidance from MT_Dialog above). It may however be susceptible to the CUSTSx_BUSY bug as noted. Indications in our application are relatively rare so we may not have seen this issue yet.

此外,SDK 6.0.6.427中包含的BLE_APP_ALL_IN_ONE示例使用CUSTS1_VAL_IND_REQ消息来发送user_svc1_long_val_cfg_ind_handler()函数中的指示。

PM_Dialog
Offline
Last seen:3 days 9 hours ago
Staff
加入:2018-02-08 11:03
Hi mkelwood,

Hi mkelwood,

In SDK 6.0.6 you are able to use the CUSTS1_VAL_IND_REQ message to send indications. As, you have already mentioned the ble_app_all_in_one example uses this message and the appropriate handler when you receive a CUSTS1_VAL_IND_REQ message. Furthermore, it is highly recommended to use the latest SDK_6.0.8 for the DA14585 device.

Thanks, PM_Dialog