Responding in this thread -- I have seen the same behavior.
In particular, bleapptimer_startFineTimer() starts the timer, but bleapptimer_stopFineTimer() does not seem to work.
The only way I was able to keep the fine timer off was to never call bleprofile_regTimerCb() or StartTimer() or bleapptimer_startFineTimer().
At one point I set the fine timer to 1000 and called regTimerCb() in an effort to get just the coarse timer, but I am not sure whether the fine timeout was still happening, at not quite the same time. The plot here shows what I observed that made me wonder this:
In this plot, the blue is my application running using an external RTC timer interrupt to drive its 'coarse' timer function. The green is using bleprofile_regTimerCb() and bleprobile_StartTimers() with fine timeout set to 1000 and NULL for the fine callback. It looks like the processor is staying awake for a long time, perhaps waiting for the fine timer to fire which is not quite synchronized with the coarse timer? That was my best guess -- not sure what other explanation there might be. The rest of the code is the same, I am just invoking the handler as the coarse timer callback rather than as an interrupt handler. (note that the time axis is in 1/3 milliseconds, y axis is microamps.)
Update: I tried not using regTimerCb() and StartTimers() and instead using bleapptimer_startAppTimer() and this seems to avoid the extra long period of being awake. So it appears that as long as you avoid regTimerCb and StartTimers the fine timer will stay off (and probably my problem in the green trace was related to the fine timer).
Since fine timers don't seem to work, I am using the bluetooth clock timer (Wiced-Smart/tier2/brcm/libraries/inc/bt_clock_based_timer.h) instead for fine timers, which can be turned on and off.
It seems not until now