Detailed description
This PR addresses an issue in the platform timeouts subsystem where the firmware will execute and handle timeouts very wrongly for a few seconds after ~49.7 days of uptime.
The gist of the bug is that as the time_ms counter approaches UINT32_MAX and platform_timeout_set() starts generating expiration times close to 0, the comparison for whether the timeout has expired will incorrectly determine that it has at the start of the timeout validity interval. This is incredibly wrong and will cause all manner of broken behaviour in anything that depends on timeouts to function properly.
We fix this by detecting this edge condition where the uptime counter has the MSb set and the expiration time does not and force the comparison to false. This is wrong if a timeout is requested that is exceedingly large (~231ms) but as the firmware never does that and that would be a ~25.8 day timeout, this edge-case is irrelevant.
Your checklist for this pull request
Closing issues
<!-- Filling this template is mandatory -->
## Detailed description
This PR addresses an issue in the platform timeouts subsystem where the firmware will execute and handle timeouts very wrongly for a few seconds after ~49.7 days of uptime.
The gist of the bug is that as the time_ms counter approaches UINT32_MAX and platform_timeout_set() starts generating expiration times close to 0, the comparison for whether the timeout has expired will incorrectly determine that it has at the start of the timeout validity interval. This is incredibly wrong and will cause all manner of broken behaviour in anything that depends on timeouts to function properly.
We fix this by detecting this edge condition where the uptime counter has the MSb set and the expiration time does not and force the comparison to false. This is wrong if a timeout is requested that is exceedingly large (~2<sup>31</sup>ms) but as the firmware never does that and that would be a ~25.8 day timeout, this edge-case is irrelevant.
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app))
* [x] I've tested it to the best of my ability
* [x] My commit messages provide a useful short description of what the commits do
## Closing issues
<!-- put "fixes #XXXX" here to auto-close the issue(s) that your PR fixes (if any). -->