Custom ChipDie

[lpbeliveau-silabs]

Issue Link:
n/a

Description of Problem/Feature:
Our ChipDie was happening silently, causing chips with a dead ChipTask to appear as if they were still functioning.

Description of Fix/Solution:
Added custome ChipDie files in matter_sdk, this adds these files to the slc components.

Testing Done:
Build, Flash, ChipDie on : BRD4116A, BR4408A, BRD4338A

[Copilot]

Pull request overview

This PR addresses an issue where ChipDie was occurring silently, making chips with a dead ChipTask appear as if they were still functioning. The fix introduces custom ChipDie implementation files in the matter_sdk and adds them to the SLC component configurations.

Changes:

• Updated matter_sdk submodule to a new commit containing the custom ChipDie implementation
• Added ChipDie.h header file to the include paths for all platform configurations
• Added ChipDie.cpp source file to the build configuration for all platform configurations

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
third_party/matter_sdk	Updates submodule commit to include custom ChipDie implementation
slc/component/matter-core-sdk/siwx917.slcc	Adds ChipDie.h and ChipDie.cpp to SiWx917 component configuration
slc/component/matter-core-sdk/efr32_wifi.slcc	Adds ChipDie.h and ChipDie.cpp to EFR32 WiFi component configuration
slc/component/matter-core-sdk/efr32.slcc	Adds ChipDie.h and ChipDie.cpp to EFR32 component configuration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Sarthak-Shaha]

Is this intended for the 2.8.0 release or patch1?

[rerasool]

Need to align if this is required for 2.8.0 as we are at code freeze. Otherwise hold merging until the branch is open for 2.8.1.

[lpbeliveau-silabs]

Need to align if this is required for 2.8.0 as we are at code freeze. Otherwise hold merging until the branch is open for 2.8.1.

We do not open branches for 2.8.x, at least we have never done it in the past. I am not extremely familiar with the process, but it seems, rather than freezing every PR until a certain moment, we should put a tag on the commit at code freeze, and then we do not need to have someone actively putting change request every time a PR opens.

[rerasool]

Need to align if this is required for 2.8.0 as we are at code freeze. Otherwise hold merging until the branch is open for 2.8.1.

We do not open branches for 2.8.x, at least we have never done it in the past. I am not extremely familiar with the process, but it seems, rather than freezing every PR until a certain moment, we should put a tag on the commit at code freeze, and then we do not need to have someone actively putting change request every time a PR opens.

Agreed, this phase could be optimized. At this point, we're only expecting a pointer bump to pick up the final SiSDK/WC build number for completeness (limited to doc and project upgrade metadata change that shouldn’t impact Matter). One option could be to create a temporary 2.8.1 branch to open it up for patch1 and then merge back into 2.8 once the release is out. It may not be worth the overhead though for just a couple of days. I defer to @jmartinez-silabs.

[jmartinez-silabs]

We can wait a few days before merging this. Once release loop is closed