Hi, the described behavior of automatic disconnections, particularly after merging low-power examples, often indicates potential areas for review in system state management, clock configurations, or interrupt handling during the sleep-to-wake transitions..
1. Thorough Review of the Sleep/Wake Sequence
It is crucial to ensure the meticulous saving and restoring of the state of all pertinent peripherals, with particular attention to those associated with Bluetooth functionality, prior to entering and upon exiting sleep mode.
The directive that “some asyn clock should be disable by software” (Section 4.1) also warrants careful attention to ensure critical Bluetooth clocks are managed correctly.
Besides, given Bluetooth’s sensitivity to clock stability (pls refer to Sections 2.1, 2.2 for details on the clock tree and registers), it is imperative to verify that the Bluetooth module can accommodate this clock transition and that the system clock is restored with precision upon wakeup. Any inaccuracies here can lead to operational instability.
2. Consideration of the Bluetooth Module’s Low-Power State:
Prior to the MCU entering sleep, it is advisable to ensure the Bluetooth module itself is transitioned into an appropriate low-power state (such as sniff mode for A2DP) that is compatible with the MCU’s sleep state and potential clock alterations, or that it possesses the capability to trigger a wakeup if required.
3. Interrupt Handling and Prioritization (Manual Section 5):
The manual indicates a high interrupt priority for Bluetooth.
It is important to ensure that your timer-based sleep mechanism does not inadvertently delay or obstruct critical Bluetooth interrupts, as this could precipitate link supervision timeouts and subsequent disconnections.
