BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Wed, 17 Oct 2018 17:56:40 GMT

Absolutely correct! Thanks so much! I've found a solution that works well in the current code base,

Alex

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Wed, 17 Oct 2018 13:48:55 GMT

Hello,

The issue is that the m_cts_c, which was defined in tnd_ble_cts_c.h is never updated in tnd_ble_cts_c.c, so it doesn't get the updated pointer to the p_cts->evt_handler in current_time_read() in ble_cts_c.c.

The problem is that when you have this type variable in a header file, all the other files that include this header file and uses the variable will generate an own instance of the variable. The solution is to use declare this variable in a .c file, and use extern for all other files that need access to this parameter.

This is easy when you have it in the main.c file, because you don't need to pass this variable around. When you have it in a different file, you must use extern. Since it is a static, you can't use extern as it, so you might have to change the macro (BLE_CTS_C_DEF()).

The easier solution is to move it to the main.c file, but if you want to separate it into a different file, you must work around this issue.

Best regards,

Edvin

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Tue, 09 Oct 2018 15:47:20 GMT

Thanks so much!

Alex

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Tue, 09 Oct 2018 06:43:39 GMT

Hello,

I have replicated your issue, but not found the cause yet. I will try to figure this out and get back to you.

Best regards,

Edvin

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Fri, 05 Oct 2018 09:02:48 GMT

Of course! I'll contact you privately

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Fri, 05 Oct 2018 09:01:19 GMT

Is it possible for me to reproduce this on an nRF52832 DK? If so, is it possible to send the project, so that I can take a look?

Best regards,

Edvin

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Thu, 04 Oct 2018 14:58:00 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Thu, 04 Oct 2018 14:51:08 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Thu, 04 Oct 2018 14:36:01 GMT

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.

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Thu, 04 Oct 2018 14:22:47 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Thu, 04 Oct 2018 13:36:02 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Thu, 04 Oct 2018 13:30:48 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

aTended — Wed, 03 Oct 2018 15:09:15 GMT

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

RE: BLE_CTS_C_EVT_CURRENT_TIME/INVALID_TIME events never thrown

Edvin — Wed, 03 Oct 2018 13:48:33 GMT

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