getting gatts value with nRF51822

[Morgan Redfield]

Hi There,

I want the functionality of my device to change when a value is written to a gatt characteristic. I've written an event handler that gets called whenever a write is made to the characteristic. This works correctly, but the problem is that I then can't get the value of the characteristic within this handler. I'm trying to use the sd_ble_gatts_value_get() function, and every time it is called the chip gets reset.

Thanks for any help you can give.

Here's my code:

void hex_evt_handler(ble_hex_t * p_hex, ble_hex_evt_t * p_ble_evt)
{

    uint32_t err_code = NRF_SUCCESS;

    uint8_t new_hex_status = 0;
    uint16_t len = sizeof(uint8_t);

    err_code = sd_ble_gatts_value_get(p_hex->hex_status_handles.value_handle,
	                                      0,
	                                      &len,
	                                      &new_hex_status);

    if (err_code != NRF_SUCCESS)
    {
        return;
    }

    ...
}

[Pål Håland]

Hi Morgan,

I don't know what the ble_hex_evt_t and ble_hex_t is.

The best way to get the data from the write event is doing this when receiving the ble_evt_t

switch (p_ble_evt->header.evt_id)
{
    case BLE_GATTS_EVT_WRITE:
        {
            uint8_t * p_data = p_ble_evt->evt.gatts_evt.params.write.data;
            uint16_t length = p_ble_evt->evt.gatts_evt.params.write.len;

            new_hex_status = p_data[0];
        }
        break;
    default:
        break;
}

Update 18.12.2015: Added pointer declaration to the p_data

[Morgan Redfield]

Hi Pal,

I made a service called ble_hex for my application, which is based around the battery measurement service. So ble_hex_evt_t and ble_hex_t are very similar to ble_bas_evt_t and ble_bas_t.

Thanks for your input about getting the value when receiving the ble_evt_t. I'll switch to that method of doing things.

I'm still wondering why the sd_ble_gatts_value_get() call was causing a crash. Any ideas about that?

[Pål Håland]

Hi Morgan,

I'm not completely sure of why the chip resets, but it could be because of an assert returned from the stack.

Instead of resetting the chip in the assert handler, could you place a breakpoint there and provide information about file and line number where it is failing?

One of the reasons it could assert is if you do a lot of processing inside the event interrupt, this would be processed in high priority interrupt, and when the stack receive an interrupt it won't start that one until the processing of the application is done. The best thing is to do is calling the sd_ble_evt_get() in the main context of the application, and only read out events when you have one ready. (like setting a flag in the event interrupt) when there is no event available and no processing to be done you put your application to sleep.

BR Pål

[Maz Shar]

p_data definition should be like this right?

uint8_t * p_data = p_ble_evt->evt.gatts_evt.params.write.data;

[Pål Håland]

Yes, updated the answer with pointer declaration