cancel
Showing results for 
Search instead for 
Did you mean: 

stm32wb55 SHCI_C2_SetSystemClock() causes hardfault

rudivs
Associate

I find that when entering deep sleep using aci_gap_set_non_discoverable(), C2 would not reliably enter the ultra low  (~4uA) power consumption mode, current would jump to ~5mA.

 

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 the purpose and use of this function. I have introduced this function, using the library example, into my code but now get a hardfault after calling SHCI_C2_SetSystemClock.

 

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.

0 REPLIES 0