I want to solve the problem that the characteristic value is not the set value.

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Thu, 24 Mar 2022 09:41:08 GMT

Hi,

Good to hear you solved the issue. I did not spot that, but it makes full sense. Thank you for letting us know!

RE: I want to solve the problem that the characteristic value is not the set value.

sdi_kei — Thu, 24 Mar 2022 04:20:28 GMT

Hello.

As a result of repeated investigations, we were able to solve the problem.

The cause is that the setting of "is_value_user" was wrong as described in the code example. Previously, I wasn't using "is_value_user", so it worked fine.

The code said ".is_value_user = BLE_GATTS_VLOC_STACK", but ".is_value_user = false" was correct. Now that I've corrected the code, I can read the settings.

Best regards.

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Fri, 04 Mar 2022 13:45:41 GMT

Most of the BLE peripheral examples in the SDK includes a characteristic that is written to that you can read (though most also notify it, so you may want to disable notification if you pick for instance the Heart Rate Application example).

RE: I want to solve the problem that the characteristic value is not the set value.

sdi_kei — Fri, 04 Mar 2022 12:56:00 GMT

Hello.

I have confirmed that the response is returned when connecting with nRF Connect. However, the values are different.

I haven't had time to create a minimal example.
Is there an example in the SDK?

Best regards.

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Fri, 25 Feb 2022 11:20:48 GMT

You do not get an even in the nRF indicating that the read response has been sent. But it will be, and if it is not being delivered for some reason, then after several attempted retransmissions, the link will be disconnected with timeout as disconnect reason. As long as this does not happen, the data has been exchanged.

RE: I want to solve the problem that the characteristic value is not the set value.

sdi_kei — Fri, 25 Feb 2022 08:38:08 GMT

Hello.

I thought that by implementing it with reference to the post, the data could be sent correctly, so I added the code.
However, I don't check the received data, so I'd like to have the stack process it all.

I'm checking the process again, but I haven't solved the problem yet.

One question is, in response to a Read Request, a Read Response is returned. Is there a way to confirm that this Read Response has been sent? Will any event occur?

Best regards.

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Tue, 22 Feb 2022 08:35:18 GMT

Hi,

I see you now added code for authorization. Do you need this? (I mentioned it in my previously post as an explanation for why you don't get an event in your case, but not as a suggestion that you should do it).

[quote user="sdi_kei"]How can I read the value I set?[/quote]

If you don't use authorization, the stack will handle everything for you. As long as you update the value with sd_ble_gatts_value_set(), that value will be read when you read it. There is not really much more to say.

I suggest the following:

First figure out if. you need authorization or not. I have not seen any indication you do. If not, remove it.
Make a example that I can test on my end on a DK and explain how to test it.,
I will test and see if I spot the issue.

The reason for the above is that as mentioned, this should just work, and I am not able to spot the error. But as I am not seeing everything you do, there might be some issue somewhere else, or I might overlook something. So giving me a minimal failing example that I can run on my end should help to find the issue faster.

RE: I want to solve the problem that the characteristic value is not the set value.

sdi_kei — Tue, 22 Feb 2022 04:36:34 GMT

Hello.

[quote userid="7377" url="~/f/nordic-q-a/84913/i-want-to-solve-the-problem-that-the-characteristic-value-is-not-the-set-value/354077#354077"]You do not normally get a event on read requests, that is handled by the stack all by itself (you can use authorization if you need to though, see for instance this post).[/quote]

I created the process by referring to the link you gave me. However, when I connected and checked with nRF Connect, the data (0x00) at the 0x00000000 address was read as in the current phenomenon.

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
            ble_char_read_evt(p_ble_evt);
            break;
    
    return;     
}

static void ble_char_read_evt(ble_evt_t const * p_ble_evt)
{
    ble_gatts_rw_authorize_reply_params_t reply_params;
    ble_gatts_evt_rw_authorize_request_t  const * p_evt_rw_auth = &p_ble_evt->evt.gatts_evt.params.authorize_request;
    ret_code_t err_code;
    uint8_t    reply_data = 0x01;

    memset(&reply_params, 0, sizeof(ble_gatts_rw_authorize_reply_params_t));

    reply_params.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
    reply_params.params.read.gatt_status = BLE_GATT_STATUS_SUCCESS;
    reply_params.params.read.update = 0x01;
    reply_params.params.read.offset = 0x00;
    reply_params.params.read.len = 0x01;
    reply_params.params.read.p_data = &reply_data;

    err_code = sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.common_evt.conn_handle, &reply_params);
    APP_ERROR_CHECK(err_code);

    return;
}

[quote userid="7377" url="~/f/nordic-q-a/84913/i-want-to-solve-the-problem-that-the-characteristic-value-is-not-the-set-value/354077#354077"]I am not sure about 8 byte, as the code her clearly only works with 1 byte, and that is also the max length you specified.[/quote]

The explanation was insufficient. I'm sorry.
The code described in DevZone says that it works with 1Byte, but I also confirmed the operation with the pattern that changed this to 8Byte. This is because it is not possible to know from which address the data is being referenced with only 1 byte.

In the code I wrote, I set 0x01 to the characteristic, so I should be able to read 0x01, but in my case, it reads the data (0x00) at the address 0x00000000.

How can I read the value I set?

Best regards.

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Mon, 21 Feb 2022 09:56:43 GMT

Hi,

[quote user="sdi_kei"]Since the characteristic is set to read, it is assumed that a Read Request will be received from the connected BLE device (nRF Connect) and the data will be acquired.[/quote]

You do not normally get a event on read requests, that is handled by the stack all by itself (you can use authorization if you need to though, see for instance this post).

[quote user="sdi_kei"]In this code, it is 1Byte, but when I set the data of about 8Byte and acquired it with a BLE device, it was the same value as the address 0x00000000 in the memory. Why is the data at address 0x00000000 sent?[/quote]

I am not sure about 8 byte, as the code her clearly only works with 1 byte, and that is also the max length you specified. With this code you should always read 1, as you set the value to one after adding the characteristic. From what I see you should always receive 0x01 with this code. Perhaps there is another issue somewhere else?

If you cannot share your code, perhaps you can make a minimal failing example with just the relevant parts that I can run on my end.

RE: I want to solve the problem that the characteristic value is not the set value.

sdi_kei — Mon, 21 Feb 2022 06:46:54 GMT

Hello.

Since the actual code cannot be published, some contents are different, but we are considering such code.

// UUID Setting
#define ADV_UUID_BASE     {0x77, 0x77, 0x66, 0x66, 0x55, 0x55, 0x44, 0x44, 0x33, 0x33, 0x22, 0x22, 0x11, 0x11, 0x00, 0x00}
#define SERVICE_UUID_BASE {0x0F, 0x0E, 0x0D, 0x0C, 0x0B, 0x0A, 0x09, 0x08, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01, 0x00}
#define CHAR_UUID_BASE    {0xF0, 0xE0, 0xD0, 0xC0, 0xB0, 0xA0, 0x90, 0x80, 0x70, 0x60, 0x50, 0x40, 0x30, 0x20, 0x10, 0x00}
#define BLE_UUID_CHAR     {0x1234}

#define BLE_UUID_CHAR_MAX {1}

// Connection Handle
static uint16_t                 m_service_handle;   /**< Handle of local service (as provided by the BLE stack).*/
static ble_gatts_char_handles_t m_char_handles;     /**< Handles of local characteristic (as provided by the BLE stack).*/
static uint16_t                 conn_handle;

// Characteristic
static ble_add_char_params_t char_test_data = 
{
    .uuid                = BLE_UUID_CHAR,
    .uuid_type           = NULL,
    .max_len             = 1,
    .init_len            = 1,
    .is_var_len          = false,
    .char_props.read     = 1,
    .read_access         = SEC_MITM,
    .is_value_user       = BLE_GATTS_VLOC_STACK,
};

// UUID Base
static ble_uuid128_t ble_char_uuid_base[BLE_UUID_CHAR_MAX] = 
{
    CHAR1_UUID_BASE,
};

// set the UUID here.
static void uuid_init(void)
{
    ret_code_t    err_code;
    ble_uuid_t    adv_uuid;
    ble_uuid_t    service_uuid;
    ble_uuid_t    char_uuid;
    ble_uuid128_t adv_uuid_base = {ADV_UUID_BASE};
    ble_uuid128_t service_uuid_base = {SERVICE_UUID_BASE};

    uint8_t       test_data = 0x01;

    // advertise setting
    err_code = sd_ble_uuid_vs_add(&adv_uuid_base, &adv_uuid.type);
    APP_ERROR_CHECK(err_code);

    // service setting
    err_code = sd_ble_uuid_vs_add(&service_uuid_base, &service_uuid.type);
    APP_ERROR_CHECK(err_code);

    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &service_uuid, &m_service_handle);
    APP_ERROR_CHECK(err_code);

    // characteristic setting
    err_code = sd_ble_uuid_vs_add(&ble_char_uuid_base[0], &char_uuid.type);
    APP_ERROR_CHECK(err_code);

    add_char_params.uuid_type = char_uuid.type;
    err_code = characteristic_add(m_service_handle, &add_char_params, &m_char_handles);
    APP_ERROR_CHECK(err_code);

    char_data_set(m_char_handles, 1, &test_data);

    return;
}

// characteristic data setting.
static void char_data_set(uint16_t handle, uint8_t len, uint8_t * value)
{
    ret_code_t        err_code;
    ble_gatts_value_t char_value;

    memset(&char_value, 0, sizeof(char_value));

    char_value.len     = len;
    char_value.offset  = 0;
    char_value.p_value = value;

    err_code = sd_ble_gatts_value_set(BLE_CONN_HANDLE_INVALID, handle, &char_value);
    APP_ERROR_CHECK(err_code);

    return;
}

Since the characteristic is set to read, it is assumed that a Read Request will be received from the connected BLE device (nRF Connect) and the data will be acquired.

In this code, it is 1Byte, but when I set the data of about 8Byte and acquired it with a BLE device, it was the same value as the address 0x00000000 in the memory. Why is the data at address 0x00000000 sent?

RE: I want to solve the problem that the characteristic value is not the set value.

Einar Thorsrud — Fri, 18 Feb 2022 12:41:52 GMT

Hi,

[quote user=""]

However, although no error now occurs, the characteristic value is no longer the set value.

I don't know why this is happening. Do you have any advice?

[/quote]

What have you changed since it did work? What value do you write and what do you see? Could it be that other parts of your code sets another value, or that you do not set it at all? If you explain and show your code I can take a look and see if I spot any issues.

[quote user=""]Also, I am currently inquiring with this ticket, but I am creating a process to switch the advertised UUID. Isn't this advertisement UUID and service UUID need to be linked? I searched for such a process, but couldn't find it.[/quote]

If you advertise a service UUID, then that indicates that your device supports that service. There is however no direct link, so you can technically advertise any UUID(s) regardless of what services the peripheral actually implements. For instance if you take a look at examples\ble_peripheral\ble_app_hrs\main.c you can see some UUIDs that are part of the advertisement packet by looking at how m_adv_uuids is declared. Implementation-vise this is completely independent of adding the services themselves.