Aslak,
I was able to get it to happen in the SimpleBLEPeripheral example project by making the following modifications:
- Define SBP_PERIODIC_EVT_PERIOD to 0
- Modify hal_key so that the interrupt generates an event on the SimpleBLEPeripheral task directly so that it can start advertising [I created an event that is handled in SimpleBLEPeripheral_ProcessEvent() that just calls simpleBLEPeripheral_HandleKeys(0, HAL_KEY_SW_2), and then in halKeyPort0Isr() I just call osal_set_event(simpleBLE_taskID, START_ADVERTISING_EVENT)]
- Turn off the non-interrupt hal_key code (debouncing and polling until buttons released) by commenting out calls to HalKeyConfig() in OnBoard_KeyCallback()
It still happens less frequently than my custom code, but I've looked into it that a little more as well. The steps above all do things that reduce the cycle time of the main loop (osal_run_system). They reduce the number of timers that are in use (the periodic timer, timer for key debouncing, and timer for key polling). This speeds up the main loop because the remaining time is updated for all timers each time through the main loop.
To test the idea that it was this added delay that prevents the problem, I modified my code to insert a busy-wait after turning on advertising. I also removed the code that I mentioned in my first post that keeps the device from going to sleep. With this busy wait in place advertising started every time. Without the busy-wait I have frequent failures. I did not play with the busy-wait to see how long it needed to be.
I look forward to trying v1.3. It would be nice if that fixes this problem.
Nick
