Fix us_ticker for NRF52 series

[marcuschangarm]

Description

Changed comparison function when setting ticker timeout to fix
tickers not set correctly.

Pull request type

[x] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

[marcuschangarm]

@studavekar this might improve the lp_ticker_timeout problems we've been seeing.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1909
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6796/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[studavekar]

@0xc0170 @cmonr

we would need multiple morph test on this PR , to make sure if the fix actually works. Also, this would be on high priority as lp_timeout fails inconsistently for NRF52 devices causing a lot of PR to be re-triggered.

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1556
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6796/

[mbed-ci]

Test : SUCCESS

Build number : 1727
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6796/1727

[0xc0170]

/morph test

[0xc0170]

I'll run today 2 more rounds (at least 3 test runs)

[mbed-ci]

Test : SUCCESS

Build number : 1737
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6796/1737

[marcuschangarm]

/morph test

[mbed-ci]

Test : SUCCESS

Build number : 1741
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6796/1741

[studavekar]

/morph test

[mbed-ci]

Test : SUCCESS

Build number : 1744
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6796/1744

[fkjagodzinski]

I looked at this PR in reference to #6732 and found one thing worth clarifying.

[fkjagodzinski]

I might have missed something, but if compare_value is equal to the current RTC ticks value, that is compare_value == common_rtc_32bit_ticks_get(), this condition will be false and an invalid value will be written to CC register. Was that intentional? That new condition might well be replaced with: if (compare_value + 1 == closest_safe_compare).

[marcuschangarm]

I think you are right. It should have been <= 2 in the comparison. However, the new 5.9 tickers are about to land so I don't think we should fix this.