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.