Why the fine timer will In what situation the fine time will fail to be started up when created though the wiced_bt_app_start_timer() API in BTM_ENABLED_EVT event thread?
The fine timer created by wiced_bt_app_start_timer() failed to start up the fine timer handler when spend more than 150ms processing in BTM_ENABLED_EVT event.
When the BTM_ENABLED_EVET event was received, I firstly spend more than 150ms to do some initialization processes, then call the wiced_bt_app_start_timer(1, 25, second_timer_handler, fine_timer_handler) to create the second timer handler and fine timer handler.
In the fine_timer_handler, just add 1 each time to a int fine_count variable. In the second_timer_handler, just output the fine timer fine_count variable through WICED_BT_TRACE through PUART.
The test result is a little timer later after called the wiced_bt_app_start_timer() function, the second_timer_handler started and output through PUART successfully, I but the fine_timer_handler never called in, the fine_cont value always 0.
If reduce the process time by remove all time-consuming processes in the BTM_ENABLED_EVT event, then the fine_timer_handler can be called, the fine_cont value is increased correctly.
By further debug, I move the long time PUART operation to the thread that when the BTM_LOCAL_IDENTITY_KEYS_UPDATE_EVT was received, and it could solve the fine timer not work issue.
But don't know why this will happen, if anyone can help explain in details, it will help a lot?
And also, following phenomenon is strange.
if do not move the PUART operation in the BTM_ENABLED_EVET, I found that the fine timer not work issue seems relative to the wiced_hal_puart_register_interrupt(puart_rx_cbk) function.
Because if removed the call of wiced_hal_puart_register_interrupt() function, the fine timer will always work fine, but if callled the wiced_hal_puart_register_interrupt() function even the handler routine puart_rx_cbk() do nothing, the fine timer still doesn't work.
So, don't know if it's really relative to the wiced_hal_puart_register_interrupt() function, and needs help to explain it.
I am not able to reproduce the issue. Even with puart_register_interrupt() API, the fine timer works in my application. I think this has something to do with the way you are calling the APIs in your application. Can you post a snip of your application.
Sorry, I cannot paste the code, it's still in developing.
When the issue happen in my case, there is no special usage with the wiced_bt_app_start_timer() function.
The timer handlers only increase the count, and in the second timer also output the debug message through the PUART.
Also, before the wiced_bt_app_start_timer() function was called, another millisecond timer was initialized.
And I measured the total time that spent in the BTM_ENABLED_EVET was about 450~500ms.
Currently, by move some of the operations to the BTM_LOCAL_IDENTITY_KEYS_UPDATE_EVT event, these issue has been solved.
It didn't happen again with multiple reboot testing.
Are you making use of wiced_bt_app_start_timer()? If yes, note that this API initializes and starts the timer. You don't have to start the timer explicitly.
Or are you calling the wiced_init_timer and wiced_start_timer APIs?
Just the wiced_bt_app_start_timer() is used after all initialization and process are done.
And one more phenomenon I found when do the testing, don't know if it is relative to this issue, but may supply some hint.
Depending on the log, the WICED stack boot BTM event sequence is:
When step b takes too much time to return, the step c and step d will be received after about 7~9 seconds later.
But if step b finish and return quickly, the step c and step d will be received immediately after step b.
So, when step b takes too long time, will firmware boot time will take about 8~10 seconds, it should be abnormal.