BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

[aTended]

Hi,

I am using SDK14.2, s132, with nRF Connect on Android.

I have used my own implementation of the CTS_C BLE service. The chip is able to detect, and request the current time, with nRF Connect showing that it sends the correct time over.

However, neither the BLE_CTS_C_EVT_CURRENT_TIME or BLE_CTS_C_EVT_INVALID_TIME events are triggered.

I have tried the ble_app_cts_c example hex, and it works fine.

EDIT: To further add to this: the event BLE_GATTC_EVT_READ_RSP is never called in ble_cts_c_on_ble_evt. The BLE_GAP_EVT_CONNECTED event is called, so the handler is definitely working.

[Edvin]

You are probably missing some handling behind the CTS_C service. Can you see if there is any difference between your implementation of CTS_C service and the implementation in the example?

Best regards,

Edvin

[aTended]

You were correct - I was adding the CTS_C service to the uuids_complete, not uuids_solicited. I created an app_timer based retry of the ble_cts_c_current_time_read function, in order to avoid the NRF_ERROR_BUSY error. It does work, and I now read the date correctly. However, I am now getting a sigtrap thrown in newlib-nano, specifically in locale.c.

313: #ifndef _MB_CAPABLE
   314:   if (locale)
0x00000000 00 04                lsls r0, r0, #16 
   312: {
0x00000002 00 20                movs r0, #0 
   315:     { 
   316:       if (strcmp (locale, "POSIX") && strcmp (locale, "C")
0x00000004 E9 08                lsrs r1, r5, #3 
0x00000006 00 00                movs r0, r0 
0x00000008 7D 05                lsls r5, r7, #21 
0x0000000a 00 00                movs r0, r0 
0x0000000c C9 08                lsrs r1, r1, #3 
0x0000000e 00 00                movs r0, r0 
   317: 	  && strcmp (locale, ""))
   318:         return NULL;
   319:     }
   320:   return "C";
0x00000010 87 05                lsls r7, r0, #22

Are these issues connected?

This sigtrap reliably occurs after the CTS_C read.

EDIT: The point at which it enters the sigtrap is from line 277 in current_time_read, in ble_cts_c.c

273:                 // Valid time reveiced.
   274:                 evt.evt_type = BLE_CTS_C_EVT_CURRENT_TIME;
0x0002bc88 03 23                movs r3, #3 
0x0002bc8a 3B 72                strb r3, [r7, #8] 
   275:             }
   276:         }
   277:         p_cts->evt_handler(p_cts, &evt);
0x0002bc8c 7B 68                ldr r3, [r7, #4] 
0x0002bc8e 1B 68                ldr r3, [r3, #0] 
0x0002bc90 07 F1 08 02          add.w r2, r7, #8 
0x0002bc94 11 46                mov r1, r2 
0x0002bc96 78 68                ldr r0, [r7, #4] 
0x0002bc98 98 47                blx r3 
0x0002bc9a 00 E0                b.n 0x2bc9e <current_time_read+120> 
   247:         return;
0x0002bc9c 00 BF                nop  
   248:     }

[Edvin]

Hello,

To be honest, I don't know why it behaves like this. But why did you have to avoid the NRF_ERROR_BUSY? did it return that all the time? I tried the ble_app_cts_c example, and I see that it returns this if I press button 1 two times in a row. That is, one more time before I get the response which is printed in the log. Do you get NRF_ERROR_BUSY if you only call it once?

Best regards,

Edvin

[aTended]

Hi, 

So NRF_ERROR_BUSY occasionally occurs during the connection/bonding process, which is when we do the CTS_C read. As a result, if the err_code returns as NRF_ERROR_BUSY, I retry after a second, which allows the bonding process to complete. It will repeat until it works. Is there a better way to do this?

Alex

[Edvin]

If this function is called before you are connected, or before the service is discovered, it should return NRF_ERROR_INVALID_STATE or BLE_ERROR_INVALID_CONN_HANDLE.

But that being said, the fact that it returns NRF_ERROR_BUSY doesn't "destroy" anything else, but I think it is only returned if you have another sd_ble_gattc_read procedure already in process.

You can alternatively wait to call ble_cts_c_current_time_read() until you get the BLE_CTS_C_EVT_DISCOVERY_COMPLETE event.

Then you can check if ble_cts_c_current_time_read() returns NRF_SUCCESS. If it does, it is no point in calling it again until you get the BLE_CTS_C_EVT_CURRENT_TIME event before you call it again.

Does it return NRF_ERROR_BUSY before it returns NRF_SUCCESS if you try this?

Best regards,

Edvin

[aTended]

So having the retry function was due to that fact I thought there was an sd_ble_gattc_read occurring. Therefore, retry after a period.

The ble_cts_c_current_time_read() is called on the BLE_CTS_C_EVT_DISCOVERY_COMPLETE event, after ble_cts_c_handles_assign is called, and successful.

I will get NRF_ERROR_BUSY back from ble_cts_c_current_time_read, unless I do the retry.

[Edvin]

Ok. But does it ever return NRF_SUCCESS, in one of the retries?

[aTended]

It does! The sigtrap fires in ble_cts_c.c, after assigning the evt_type as BLE_CTS_C_EVT_CURRENT_TIME. I can even see in the evt params it has the correct time and date.

It fires specifically, every time, on p_cts->evt_handler(p_cts, &evt);