Invalid length return from sd_ble_gatts_value_set

[John]

I have a feeling I am missing something completely obvious here. That said, this problem has cost me enough time today that I'm willing to risk embarrassment to see if someone can point out whatever mistake I am making here. This is on an older product that is running the 6.0.0 S110 soft device. I am calling sd_ble_gatts_value_set() via ble_dis_sw_rev_update() to update the software revision field of the device information service. I have been getting NRF_ERROR_DATA_SIZE returned as a result of this code:

char		fw_minor_revision_str[4] = {0};
uint8_t		fw_rev_minor;
uint32_t	err_code;
ble_srv_utf8_str_t encoded_fw_str;


fw_rev_minor = serial_message.msg.bfr.data[1];
itoa((uint32_t)fw_rev_minor, fw_minor_revision_str);
ble_srv_ascii_to_utf8(&encoded_fw_str, fw_minor_revision_str);
err_code = ble_dis_sw_rev_update(encoded_fw_str.p_str, encoded_fw_str.length);

The ble_dis_sw_rev_update() function looks like:

uint32_t ble_dis_sw_rev_update(uint8_t * sw_rev_string, uint16_t length) {
return sd_ble_gatts_value_set(sw_rev_handles.value_handle, 0, &length, (uint8_t *)sw_rev_string);}

Any thoughts would be appreciated.

[Nguyen Hoan Hoang]

You length is probably bigger than the max length set in the service init. May be it was meant to be binary number instead of ascii. I suggest to check the service implementation code.

[John]

Interesting thought that I hadn't considered. The starting revision is 0x02 and the end revision is 0x32 so the length when they are converted to strings via itoa are likely different. I'll experiment and post back the results.

[John]

Thanks. That was indeed the case causing the failure I am seeing. The API works correctly when starting from revision 0x30 to 0x32 because the string sent to the stack during init was 2 bytes long instead of 1. Not a case discussed in the documentation for that failure return code.