This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

getting gatts value with nRF51822

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;
    }

    ...
}


Parents
  • 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

Reply
  • 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

Children
No Data
Related