ble_app_gzll & freeRTOS & peer manager

RE: ble_app_gzll & freeRTOS & peer manager

cp52 — Thu, 07 Sep 2017 13:37:59 GMT

When are the start up routines run? On power up? Is this still true if we go in to low power mode and then come back out of it?

RE: ble_app_gzll & freeRTOS & peer manager

emdi — Thu, 07 Sep 2017 13:29:12 GMT

m_users is a static variable and is zero-initialized by the startup routines when the program starts.

RE: ble_app_gzll & freeRTOS & peer manager

ypearson — Thu, 07 Sep 2017 02:06:37 GMT

I'm having a similar issue, I had to patch app_timer_freertos.c to allow re-initialization.

Any new insights ?

RE: ble_app_gzll & freeRTOS & peer manager

cp52 — Tue, 29 Nov 2016 12:33:40 GMT

Another recommendation: There is no initial state for m_n_registrants. It should be set to 0 in the initialisation and probably when it is defined. Otherwise I dont think can we guarantee its value on start up. static uint8_t m_n_registrants = 0;

RE: ble_app_gzll & freeRTOS & peer manager

cp52 — Mon, 28 Nov 2016 13:24:13 GMT

Unfortunately I cant do this as we are using the other timers and RTC's.

RE: ble_app_gzll & freeRTOS & peer manager

cp52 — Fri, 25 Nov 2016 14:57:46 GMT

Ok So here are the fixes for running peer manager when you need to stop and restart the Ble app

Note: my project is based on the ble_app_hrs_freertos which has been modified to behave like the ble_app_gzll project so that the ble stack can be stoped and started

ble_conn_state_init(); needs to be run on the initialization of the ble. Before the peer manager in initialised. This clears all the flags other wise the pm_init()->gcm_init() can not acquire them.

ble_app_hrs_freertos: (tested)

Add ble_conn_state_init(); to the static void ble_init(void) function

ble_app_gzll project: (not tested)

ble_app_gzll_hr.c -> Add ble_conn_state_init(); to the void ble_stack_start(void)function

Non urgent as I can fix this myself as it is not part of an SDK library/component.

2)m_n_registrants needs to be reset to 0 on initialisation. This clears the event handlers and allows new ones to be registered using the pm_register(pm_evt_handler). Other wise each time the peer_manager_init() is run it will register the event again and fill up the buffer.

Please can a fix\ patch be put in for this. I need a way of setting m_n_registrants to 0. Urgent as it requires a change to the peer manager which is a SDK library/component.

This could either be done in ret_code_t pm_init(void) or by making a new function to clear events. Im not fussed.

3)There is now a third issue with the fds module. It is the same scenario as in the peer manager.

at no point is m_users set to 0! This could be a bug if the memory location at m_users is not 0 on start up!

in my opinion this should be set to 0 when initialized and in the fds_init() function.

RE: ble_app_gzll & freeRTOS & peer manager

Susheel Nuguru — Fri, 25 Nov 2016 10:36:02 GMT

Then use the patch and use app_timer.c instead of app_timer_freeRTOS.c . Then you will still have the exact same behavior you had when you were not using FreeRTOS.

RE: ble_app_gzll & freeRTOS & peer manager

cp52 — Fri, 25 Nov 2016 09:44:24 GMT

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.

RE: ble_app_gzll & freeRTOS & peer manager

Susheel Nuguru — Fri, 25 Nov 2016 08:41:19 GMT

FreeRTOS and app_timer.c both uses RTC1. Can you use app_timer_freertos.c instead of app_timer.c? The first one uses RTOS timers instead of RTC1

I am not sure if the second problem is related FreeRTOS?

I am attaching a patch for SDK12.1, that will make FreeRTOS use RTC2 instead of RTC1, incase you still want to use app_timer.c instead of app_timer_freertos.c, keeping you app functionally same.

change_freeRTOS_to_use_rtc2_instead_of_rtc1.patch