[bootloader] Implement bootloader reset reasons

[scott-brust]

Problem

The RTL bootloader has not been updated to use the backup register HAL to communicate reset reason to the system part application. This leads to undefined reset reasons in the following scenarios

1. When completing OTA bootloader update
2. When completing DFU update via button reset/hold

Solution

The backup register HAL is implemented on RTL platform via retained SRAM, the bootloader just needs to write the "registers"

Steps to Test

Checkout branch, compile bootloader, flash
Flash app via reset button hold and DFU
Log reset reason ie (Log.info("Last Reset Reason %d", System.resetReason());)
Verify that it is correct (70 = firmware update, 40 = pin/power reset):

0000008051 [app] INFO: Last Reset Reason 70

Without bootloader update, the values are undefined:

0000058978 [app] INFO: Last Reset Reason -49520187

Example App

References

See comment here

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[eberseth]

Just a general question on whether we should be providing a reason for disconnection in the vitals publish as well? I did a button reset and the disconnect reason was "none". I then powered off my msom and got a reason of "unknown".

{
  "connection": {
    "status": "connecting",
    "error": 0,
    "attempts": 1,
    "disconnects": 0,
    "disconnect_reason": "none",
    "interface": "Cellular"
  },
  "coap": {
    "transmit": 9,
    "retransmit": 0,
    "unack": 0,
    "round_trip": 1526
  },
  "publish": {
    "rate_limited": 0
  }
}

[monkbroc]

Connection vitals are not very useful. The counters tend to be 0 or 1. I think it's out of scope to rework that to be something more useful right now, but worth considering perhaps as part of ACM work.

[eberseth]

Connection vitals are not very useful. The counters tend to be 0 or 1. I think it's out of scope to rework that to be something more useful right now, but worth considering perhaps as part of ACM work.

I agree changing it may be out-of-scope of the reason fixes. Just thinking that since we already know that we have reset for OTA or other that it would be easy to determine and report.

[scott-brust]

Connection vitals are not very useful. The counters tend to be 0 or 1. I think it's out of scope to rework that to be something more useful right now, but worth considering perhaps as part of ACM work.

I agree changing it may be out-of-scope of the reason fixes. Just thinking that since we already know that we have reset for OTA or other that it would be easy to determine and report.

The vitals mostly contain system diagnostics stuff. The "connection" structure you point out is mostly the "Network" diagnostics. There are similar "Cloud" diagnostics (ie connect attempts, disconnects, disconnect reason). I dont know how well the Network disconnect reason diagnostic works

These are distinct from the System.resetReason(), which is not stored as a system diagnostic. I dont know if this is included in the vitals publish or not. I believe it should be published as a separate event

[scott-brust]

Pulling in changes from #2771