Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Tim — Tue, 10 Dec 2019 17:11:08 GMT

A bit more info ...

If I add nrf_delay_ms(50) after NRF_RTC1->TASKS_STOP=1 and before NRF_RTC1->PRESCALER=255, it appears that the prescaler is set correctly every time. Still, though, I'm concerned about using RTC1 before ble_conn_params.c/app_timer have finished using it.

Thx!
Tim

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Tim — Tue, 10 Dec 2019 16:42:14 GMT

Thanks mrono. I agree, somehow writing my own app_timer would be ideal. I'm new to low-level BLE and Nordic SDK and do not understand ble_conn_params.c well enough to safely do this. I've noticed that on the occasions where PRESCALER is 0 after I set it to 255, about 3 seconds later app_timer's RTC1 interrupt routine (RTC1_IRQHandler()) is called. This, I think, suggests that following successful connection between central and peripheral, a timer created by ble_conn_params.c is still running and a timeout or CC event occurs.

I'd be grateful for any guidance on either 1) removing use of ble_conn_params.c and implementing connection parameter negotiation myself (and hence removing its dependence on RTC1, or at least knowing how it uses RTC1 so I can be sure my app's use of it doesn't interfere (or vice versa), or, as you say, 2) implement my own reduced version of app_timer. How to go about that?

Appreciate any guidance. Many thanks,

Tim

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

mrono — Tue, 10 Dec 2019 10:20:23 GMT

I think the simplest way would be to implement your own reduced version of app_timer, and replace the calls to app_timer_start/stop in ble_conn_parameters with your own functions. Then you'd be in complete control over RTC1.

If it is only the conn_params -module that needs app_timer, then you could even restrict your implementation to only have one timeout running at a time.

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Tim — Tue, 10 Dec 2019 07:28:42 GMT

I thought I had a solution for this, but need to revisit.

Experiencing an intermittent issue whereby somehow RTC1's prescaler is being set to 0. My app was built by starting with ble_app_uart and removing uart and customizing. Here's how my app currently utilizes RTC1:

1) Following connection between BLE peripheral and central (ble_evt_handler(..) receives BLE_GAP_EVT_CONNECTED in p_ble_evt->header.evt_id), peripheral and central exchange a bit of data (nus_data_handler(..) to receive from central, ble_nus_data_send(..) to send to central).

2) At this point my app assumes that ble_conn_params.c is done using app_timer/RTC1, and proceeds to set up and start RTC1 with prescaler 255:

NRF_RTC1->TASKS_STOP = 1;   // Stop RTC1
NRF_RTC1->TASKS_CLEAR = 1;  // Clear RTC1
NRF_RTC1->PRESCALER = 255;  // Set RTC1 prescaler
NRF_RTC1->TASKS_START = 1;  // Start RTC1

NVIC_ClearPendingIRQ(RTC1_IRQn);
NVIC_DisableIRQ(RTC1_IRQn);

uint16_t current_prescaler = NRF_RTC1->PRESCALER;
NRF_LOG_INFO("current_prescaler %d", current_prescaler);

Sometimes NRF_LOG_INFO shows current_prescaler to be 255, sometimes 0. It seems that even at the point a central/peripheral connection has been established, ble_conn_params.c may still be using app_timer/RTC1. Even though my app sets prescaler to 255, app_timer might be setting it back to 0?

Is there a way I can know for sure when ble_conn_params.c is done with app_timer/RTC1 so my app can safely use RTC1?

I guess another option is to not use ble_conn_parameters/app_timer, but I don't know how to do that. If simple, I'd appreciate the code to do so.

Many thanks,

Tim

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Tim — Thu, 07 Nov 2019 16:48:21 GMT

Thank you Håkon. I'll take a closer look at ble_conn_params.c.

Tim

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Håkon Alseth — Thu, 07 Nov 2019 11:47:49 GMT

To update your connection parameters, its essentially a call to "sd_ble_gap_conn_param_update" that is performed x amount (configurable) of seconds after the connection has been established - based on if this is needed by the timing that has already been provided to you by the central device. It has a bit more logic in ble_conn_params.c, where it for instance handles retries.

Kind regards,

Håkon

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Tim — Wed, 06 Nov 2019 15:58:02 GMT

Thank you Håkon. I'll proceed with currently working solution. However, I'd still be curious about how to handle connection parameters without the Connection Parameters Negotiation library, as suggested in this post:

You should however note that the connection parameters module isn't strictly required, since you can send connection parameter update requests manually by using the softdevice API directly. All modules using app_timer are optional, and you can just avoid using them.

I have a feeling this might be quite involved. Thanks either way.

RE: Removing Connection Parameter Negotiation BLE library from ble_peripheral ble_app_uart example app

Håkon Alseth — Wed, 06 Nov 2019 13:18:40 GMT

Hi,

[quote user=""]I've implemented this and it appears to work well but I'm concerned about the risk of manipulating RTC1 while ble_conn_params.c is using app_timer/RTC1.[/quote]

The RTC1 peripheral is only used by app_timer, and if you, in your application, have total control over when the app_timer uses it, I do not see any reasons why you shouldn't go forward with that.

If you can use the same prescaler in app_timer as in your application, you could also modify app_timer.c (irq handler) to check other events than EVENTS_COMPARE[0], as app_timer only uses CC[0] to handle its own queue, so if you ensure that app_timer newer stops the RTC, and you modify the irq-handler; you can use those other CC instances freely.

That being said; If you have a solution that already works, I wouldn't change it.

Kind regards,

Håkon