I find that when entering deep sleep/range 2 using aci_gap_set_non_discoverable(), C2 would not reliably enter the ultra low (~4uA) power consumption mode, current would jump to ~5mA. I am using stack 1.18 and even 1.19.
a) Calling aci_gap_set_non_discoverable() while there is RF activity can cause CPU2 to get stuck in a spin loop and become unresponsive.
b) aci_hal_set_radio_activity_mask(0x0002) can be used to obtain an RF event ACI_HAL_END_OF_RADIO_ACTIVITY_VSEVT_CODE to synchronize call to aci_gap_set_non_discoverable() while no RF activity (assuming event is serviced in time; it is only in main() thread).
But even after successfully calling aci_gap_set_non_discoverable(), if CPU1 remains in run or sleep mode longer than about 200ms after CPU2 disables advertising, again CPU2 can get stuck in a spin loop.
The above issues can occur even if using aci_gap_set_limited_discoverable(); when 180 seconds is up there is a chance CPU2 will again just spin if condition a) or b) at the time.
After lookning at https://community.st.com/t5/stm32-mcus-wireless/stm32wb55-random-core2-hard-faults/m-p/58804. Any call to SHCI_C2_SetSystemClock would simply cause a hardfault, probably incorrect clock condiguration ? again what is the expected conditions for use when callling SHCI_C2_SetSystemClock ?
There does not seem to be any supporting documentation or comments in the library for its purpose.
As a work around I would reset the entire stack and re-init with aci_hal_stack_reset() and APP_BLE_Init(). This is more reliable but after a few hours/days run time the problem would return.
Mention is made in the release notes: "ID 152090 : Wrap round issue correction on wakeup time counter preventing periodically BLE to go in LP mode between two consecutive advertising events" I find this related to my issue somehow?
