STM32_us_ticker_16b: keep code to cope with past event

[LMESTM]

Description

Fixes test suggested in #5004.

Fixing regression introduced in commit
"Ticker: add fire interrupt now function".

In above mentioned commit, the management of timestamp being in the past
has been moved to higher layer (hal/mbed_ticker_api.c), but the reset of
oc_int was missing when implementing the new us_ticker_fire_interrupt
function - which is fixed now.

Status

READY

Todos

• Tests

[0xc0170]

cc @pan-

[0xc0170]

What is this fixing? What regression was introduced ?

I would keep the else part, but if delta is negative - should be handled by ticker implementation in the above layer ?

[LMESTM]

@0xc0170 As explained in description, this fixes #5004. The test of #5004 works fine before merge of #4644 and fails just after => this is the regression.

In us_ticker_set_interrupt we need to read timestamp again, so delta can be positive when read from above layer, then negative when reading again in us_ticker_set_interrupt. Therefore I think that we cannot get rid of this check.

[adbridge]

As this fixes a regression already introduced in a PR marked for 5.6, we need to also get this one in for 5.6.

[0xc0170]

@0xc0170 As explained in description, this fixes #5004. The test of #5004 works fine before merge of #4644 and fails just after => this is the regression.

That reading is fine, but the first condtion could be removed. have you tested it with only else there? when delta is positive. I believe it should work

[LMESTM]

@0xc0170 Before reverting the full function, I did the test with only the else part and the test fails.
My understanding of the situation is as said: In us_ticker_set_interrupt we need to read timestamp again, so delta can be positive when read from above layer, but still negative when reading again in us_ticker_set_interrupt

[LMESTM]

@0xc0170 actually this makes me think that maybe the same applies to us_ticker_32b.c except the probability is just very low ...

[0xc0170]

@0xc0170 Before reverting the full function, I did the test with only the else part and the test fails.
My understanding of the situation is as said: In us_ticker_set_interrupt we need to read timestamp again, so delta can be positive when read from above layer, but still negative when reading again in us_ticker_set_interrupt

as delta is only int (very short range), we do not know if it was in the past or in the future (it could have wrapped around by the time). We cleaned all targets , to remove this check, the upper layer does it and knows better as using 64bit timestamp.

See https://github.com/ARMmbed/mbed-os/blob/master/hal/mbed_ticker_api.c#L120 . The set interrupt function should only receive positive deltas (new match timestamp is in the future, even very near future).

Aren't we missing something else here? Fire interrupt does not touch oc int part, should it?

@pan- What is your view on this one?

[LMESTM]

See https://github.com/ARMmbed/mbed-os/blob/master/hal/mbed_ticker_api.c#L120 . The set interrupt function should only receive positive deltas (new match timestamp is in the future, even very near future).

Actually the condition of event being in the future in line 120 can have changed when line 129 is reached and the call is done, or even inside the set_interrupt function. BUT there is another sanity check few lines later here https://github.com/ARMmbed/mbed-os/blob/master/hal/mbed_ticker_api.c#L130 which does the job indeed. I first thought this may be buggy in some way, but ...

Aren't we missing something else here? Fire interrupt does not touch oc int part, should it?

Good catch. oc_int part is the counter of 16bits wrap-ups until next interrupt must be triggered. When event is in the past or when we fire interrupt, this needs to be reset to 0. When fixing this in fire_intterrupt, the tests are PASSED again. I will update my PR accordingly.

[LMESTM]

@0xc0170 I just pushed the new version of the patch

[LMESTM]

And Ticker tests passed ok

[0xc0170]

LGTM

[0xc0170]

@LMESTM 👍 Should be all OK, in case not, we should write a test (however mbed ticker API has extensive testing via mocks), and tick classes are now getting also test updates, teh coverage should increase soon

[0xc0170]

/morph test

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1223

Example Build failed!

[0xc0170]

/morph test

[mbed-bot]

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1240

Build Prep failed!

[studavekar]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1262

All builds and test passed!