P_evt_write handle doesn't match

RE: P_evt_write handle doesn't match

julienh — Fri, 29 Sep 2017 13:04:06 GMT

Peter founds the issue. That was a corruption of the RAM due to the fact that I added more value in an array than the actual size of this one.

Working fine now.

RE: P_evt_write handle doesn't match

Petter Myhre — Fri, 29 Sep 2017 08:59:42 GMT

Please send me the hex file of your program.

RE: P_evt_write handle doesn't match

julienh — Fri, 29 Sep 2017 08:55:31 GMT

We have exactely the same code. Do you think that this is possible that something is corrupted in my SDK files or my IDE? I don't know what to do...

RE: P_evt_write handle doesn't match

Petter Myhre — Fri, 29 Sep 2017 08:51:33 GMT

Yes I tried that. I always get 24/24.

RE: P_evt_write handle doesn't match

julienh — Fri, 29 Sep 2017 08:27:49 GMT

In fact it seems to be a biggest problem that what I thought. When I try to update a value with sd_ble_gatts_value_set, somtimes it's ok and sometimes error 0x05.

err_code = sd_ble_gatts_value_set(p_acs->conn_handle, p_acs->accumulated_steps_handles.value_handle, &gatts_value);

Sometimes I have p_acs conn handle 0 and p_acs->accumulated_steps_handles.value_handle 18 (success) and sometimes I have p_acs conn handle 0 and p_acs->accumulated_steps_handles.value_handle 349 (error).

As explained before, it seems to be random when I connect / disconnect the device multiple times. I'm using nRF connect on Android phone for information.

RE: P_evt_write handle doesn't match

julienh — Thu, 28 Sep 2017 22:10:45 GMT

Petter, did you try many connection / disconnection? Because I did a lot of connection / disconnection and somtimes I have 24 / 24 and sometimes I don't have the same value.

RE: P_evt_write handle doesn't match

julienh — Thu, 28 Sep 2017 16:41:09 GMT

Thanks for your fast reply. tested again with exactly the same code that I sent you and not the same result as you. You can see in the attached screenshot.

I'm just writing a value on characteristic 0x0503 with nRF Connect (Android phone).

RE: P_evt_write handle doesn't match

Petter Myhre — Thu, 28 Sep 2017 15:24:24 GMT

0x18 or 24 is the correct handle for p_acs->reset_handles.value_handle()

I tried to debug the project here, and I get 0x18 for both.

RE: P_evt_write handle doesn't match

julienh — Thu, 28 Sep 2017 13:47:08 GMT

Done (ps : the user name is different -> julienhmt).

Thank you for your help

RE: P_evt_write handle doesn't match

Petter Myhre — Thu, 28 Sep 2017 13:36:05 GMT

Yes please :)

RE: P_evt_write handle doesn't match

julienh — Thu, 28 Sep 2017 13:33:34 GMT

Hi Petter,

Thanks for your reply.

I'm checking that this is a GATTS_EVT_WRITE before sending to my on_write function which is called.

void ble_acs_on_ble_evt(ble_acs_t * p_acs, ble_evt_t * p_ble_evt)
{
  if ((p_acs == NULL) || (p_ble_evt == NULL)) {
    return;
  }

  switch (p_ble_evt->header.evt_id) {
  case BLE_GAP_EVT_CONNECTED:
    on_connect(p_acs, p_ble_evt);
    break;

  case BLE_GAP_EVT_DISCONNECTED:
    on_disconnect(p_acs, p_ble_evt);
    break;

  case BLE_GATTS_EVT_WRITE:
  on_write(p_acs, p_ble_evt);
  break;

  default:
    // No implementation needed.
    break;
  }
}

Everything seems to be good to me on ble_evt_dispatch.

I will create a case and send you the whole project. Tha will be simpler do discuss.

RE: P_evt_write handle doesn't match

Petter Myhre — Thu, 28 Sep 2017 10:01:13 GMT

Sounds strange that p_evt_write->handle is 24 when you 1 service and 3 characteristics, but what handle do you expect? The only thing I can think of straight away is that this is not actually a write event, but some other event, you could double check that p_ble_evt->header.evt_id is actually BLE_GATTS_EVT_WRITE.

I'm not sure why p_acs->reset_handles.value_handle is 117 either, but as you say it sounds incorrect. But this is forwarded from main.c isn't it? You have something like ble_acs_on_ble_evt(&m_acs, p_ble_evt); in ble_evt_dispatch() in main? Are you sure the handle is actually set? It is typically set in services_init(). Have you checked the value of p_acs->reset_handles.value_handle after it is called? If it is 117 I guess you have found the culprit. If not, you should check why this is set to 117 at a later time in your program.