Fix double low power ticker interrupt

[c1728p9]

Description

When computing the next set_interrupt time in the common ticker layer
the absolute time in microseconds is rounded down to the closes low
power tick. Because of this the low power ticker interrupt fires one
cycle too early. This causes ticker_irq_handler to run even though
there are no events ready to run.

To prevent this unnecessary interrupt this patch changes the
computation for the next set_interrupt time to round up rather than
down.

Pull request type

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

[cmonr]

/morph build

[mbed-ci]

Build : SUCCESS

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

Triggering tests

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

[mbed-ci]

Exporter Build : SUCCESS

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

[kjbracey]

To check I understand this correctly:

The schedule_interrupt tick conversion rounded down, that rounded-down tick was in the past, so it scheduled an immediate interrupt. That interrupt triggered, but ticker_irq_handler decided it wasn't time yet, so rescheduled. Repeat, spinning interrupts, until time is reached? Seems like it could be more than just double, potentially?

If that's right, then approved.

Slightly wary of it going in a patch release unless it's causing a real observed problem - vaguely possible someone's timing is somehow relying on that spin to get more accurate scheduling - it was working a bit like wait_ms.

[cmonr]

@c1728p9 Mind ack/nack-ing kjbracey-arm's interpretation?

[cmonr]

@kjbracey-arm We're close enough to the feature release that we could target it to 5.10 without too much issue. @c1728p9 any objections?

[mbed-ci]

Test : FAILURE

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

[studavekar]

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

This failed as it failed to fetch the test app from AWS

download failed: s3://mbed-os/builds/7599/PASS/NUCLEO_F401RE/ARM/testbin_c36b58a05b0211d3dafe015416d3440eecbe4966.zip to ./testbin_c36b58a05b0211d3dafe015416d3440eecbe4966.zip HTTPSConnectionPool(host='mbed-os.s3.amazonaws.com', port=443): Read timed out.
unzip:  cannot find or open testbin_*.zip, testbin_*.zip.zip or testbin_*.zip.ZIP.

[studavekar]

/morph test

[c1728p9]

Hi @kjbracey-arm yeah, that is correctly. In the setup I was using it was firing twice, but for faster devices it could fire many more times. @cmonr, this going into 5.10 sounds good to me.

[mbed-ci]

Test : FAILURE

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

[cmonr]

Hmmm, not liking the trend in silly test failures...
/morph test

[mbed-ci]

Test : FAILURE

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

[cmonr]

Failures don't appear to be related to CI.
/morph test

[mbed-ci]

Test : SUCCESS

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