ble_app_gzll & freeRTOS & peer manager

[cp52]

Hi

I am running some thing similar to the multiprotocol ble_app_gzll example but using freeRTOS and peer manager. Effectively the the main in ble_app_gzll example is a freeRTOS task.

1. The first issue I came across was reinitialising ble. (ie this is the second time the ble is started) The conn_params_init()->ble_conn_params_init() failed with the error NRF_ERROR_INVALID_STATE It looks like the timer cannot be reinitialized.

Do I have to some how delete the timer when stopping the ble task. This would mean it would behave differently to the non freeRTOS version.

I have commented out the APP_CHECK error so it continues to run. I am assuming this timer never gets destroyed which is why the osHandle is not NULL

I can now stop and start the ble module. Is there a better way of doing this?

2. However on the 3rd time of initialising there is now a problem with the peer manager. It fails in pm_init -> gcm_init() All the flags are BLE_CONN_STATE_USER_FLAG_INVALID

Any suggestions?

[cp52]

As I see it we have one app_Timer header file and we can select the implementation app_timer.c or app_timer_freertos.c or app_timer_rtx.c by compiling the one we want ( by adding it to the makefile)

I am currently using app_timer_freertos.c and it is this that has the problem. The problem comes when is run for the second time the freertos timer has already been created and so the handle is not null. The issue is that the timer isnt deleted and there is no way of doing this.

ble_app_gzll uses the app_timer.c. This isnt creating a new timer when app_timer_create() is called as it is modifying a timer that is already there so I think this is why it works.

In app_timer_freertos.c if I ignore that error I think it still works as it just uses the timer that was created the first time it was called and luckily the handle is still the same. I have just changed the code to make a delete timer function and this does fix the problem. It will be a major headache implementing this as currently there is no sensible place to run the delete function in the current architecture.