Add the EFR32 watchdog to RPC firmware

[puddly]

RPC firmware currently doesn't have a watchdog, making firmware crashes are irrecoverable without a hardware reset.

Reproducing an actual firmware crash is proving very elusive but I can confirm that the CPC daemon detects and recovers successfully from a watchdog reset.

Very briefly tested on a Yellow and things still work. I think the timers will require tweaking to ensure the watchdog reset timer is not delayed enough during heavy network load to cause an unnecessary reset.

To allow adding new components and customizing the generated SLCP files further, I've added a dependency on yq (a jq wrapper that works with YAML) to mutate the SLCP YAML directly. If we have to further customize the firmware, we may want to switch to just keeping the basic generated project structure in-tree.

[puddly]

To test this in Simplicity Studio, add the extension by modifying your project's properties and navigating to C/C++ Build > Board / Part / SDK > Manage SDKs... (small blue text):

Then, highlight your SDK and click the Add Extension... button. Select the root of the extension folder (the one with the .slcc file). Trust the extension and then restart Simplicity Studio!

After loading Simplicity Studio, click on the Software Components tab and wait 10-20s for it to load. Enable showing just SDK Extensions and you can then install it:

You may have to re-generate the project a few times or restart Simplicity Studio to get it to incorporate in the build. This is done through the three dot menu (...) under Project Details:

You can verify that it was added successfully when nc_enable_watchdog is added to autogen/sl_event_handlers.c:

Unfortunately, Simplicity Studio is very inconsistent with some of these things so you may have to restart it, force regenerate, clean, and re-build before things work.

[MattWestb]

Thanks for the deep digging and fixing !!!! I must looking adding the same for my Billys and Markus and i think i can do it with your instruction !!

And i have the same experience of SS then compiling one firmware and its not working also if only doing the hardware config and then cleaning and rebuilding its not working and then doing one new project and its working very well so its little . . . many times.

[MattWestb]

I think i have manage getting the Extension installed in SS and also installed it in the project after activating the software component and building the RCP firmware (without restarting SS it was reloading the build and it was there). The last line with it in the build log:

Finished building: C:/SS5/developer/SDKs/4310/extension/nc_efr32_watchdog_extension/src/nc_efr32_wdog.c

Now must making more versions for different comport settings and then testing it in my systems.

Great thanks Puddly i shall making one P version of my Billy and Marcus RCP firmware.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[puddly]

Not stale, just waiting

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[puddly]

It looks like this PR didn't originally work for two reasons:

1. _abort() compiles down to an endless loop, locking up the CPU.
2. The CPC timer interface runs in an interrupt context.

The result was that assert(false) would "run" and truly halt execution, but the watchdog timer would also still execute every few seconds to feed the watchdog.

Instead, this PR now sets up a 75% watchdog counter interrupt to feed the watchdog only if the main application loop has called a function to set a flag. This mitigates the problem, which I've confirmed with an intentionally-placed assert(false) in an OpenThread RX handler.

[MattWestb]

GSDK 4.4.0 is adding one sl_zigbee_watchdog_periodic_refresh.c then compiling one NCP but not then doing one RCP. Is that doing the same functionality for the NCP as the RCP you have implanting or is it somthing different ? Alos shall we putting your production WD in all new RCP firmware ? Then its best adding it in one wiki for the firmware or the builder so users can finding the information and doing it right.