[SL-TEMP] Changes 917 SoC/NCP sleep config to connected sleep

[bhmanda-silabs]

Description

• In the ConfigureDeepSleep function of the SiWx platform, setting to BLE sleep config to RSI_SLEEP_MODE_8 which is deep sleep when DUT is not provisioned. So this prevents the initial BLE connection to work since DUT can't advertise in this mode.
• This PR changes the default for all sleep configs to connected sleep which is RSI_SLEEP_MODE_2 till commissioning completed so that ble advertising and connection are working.

Testing

Verified commissioning on 917 SoC and NCP boards and commands.

[mkardous-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.

[senthilku]

This "SLI_SI917" need to be replaced with "SLI_SI91X_MCU_INTERFACE" in other places also?

[bhmanda-silabs]

"SLI_SI917" : this macro is enabled for 917 NCP and SoC boards.

[senthilku]

Are there any other places where we need to replace this macro (common code for NCP and SoC)?

[bhmanda-silabs]

No @senthilku

[bhmanda-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

[bhmanda-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

@mkardous-silabs what are the sleep states required for our matter-wifi? or any design/info on the requirements?

[mkardous-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

@mkardous-silabs what are the sleep states required for our matter-wifi? or any design/info on the requirements?

I don't have an exhaustive list of which peripherals work in each sleep state and how these peripherals behave in each sleep state. Some of this involves prototyping and testing to see how the peripherals behave and what the power consumption looks like based on the known baselines

[mkardous-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

My point is this class exists specifically to add a new feature - Selective Listening. If a big fix is done in this class, it does not get translated to CSA which doesn't have this logic. The CanGoToDeepSleep should not go in a class whos responsibility is to determine if the device can got to LI or DTIM based sleep.

[bhmanda-silabs]

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

@mkardous-silabs what are the sleep states required for our matter-wifi? or any design/info on the requirements?

I don't have an exhaustive list of which peripherals work in each sleep state and how these peripherals behave in each sleep state. Some of this involves prototyping and testing to see how the peripherals behave and what the power consumption looks like based on the known baselines

@bhmanda-silabs I'm not sure i understand the way the issue is being fixed here. We can fix the issue by always configuring BLE in the associated sleep mode which simplifies our logic.

Here, DUT can go deep sleep(BLE + WiFi sleep) when it is provisioned and commissioning window is closed. DUT will be active whenever requested for high performance.

This would also mean that all the ifdef in the ApplicationSleepManager can be removed.
Modified ifdef condition to SLI_SI917 as these checked should not be enabled for RS9116 boards.

My point is this class exists specifically to add a new feature - Selective Listening. If a big fix is done in this class, it does not get translated to CSA which doesn't have this logic. The CanGoToDeepSleep should not go in a class whos responsibility is to determine if the device can got to LI or DTIM based sleep.

Ok got it. Validated by configuring BLE and WiFi to be connected state and TA is going deep sleep state after default discovery time when it closes the commissioning window and stop the BLE. Also post-commissioning, if AP is disconnected DUT switching to low power mode.