On some platforms, if low power ticker interrupt is set to very close value (e.g. timestamp < current tick + 3), then interrupt may not fire. This is one use case of lp ticker wrapper, but not all platforms use the wrapper. Some platforms cheat a bit and in this case, simply schedules interrupt a bit later. The problem has been found while working on the low-level lp ticker wrapper for ST boards which run lp ticker using LPTIM. These platforms have such limitation.

Failing test: tests-mbed_drivers-lp_timeout (Test Case: Zero delay)

In the test scenarion, the lp ticker callback is attached with 0.0 s delay in the loop. The new events are put in the front of the lp ticker event list and interrupt reschedule is performed. Usually, the new event is already expired, interrupt fires immediately and next event from the list is then scheduled (e.g. system tick). When the next event (e.g. system tick) is very close to the current time it might be scheduled a bit later (because of lp ticker limitation). Let's assume that system tick has been delayed by 3 ticks and while inserting new zero delay event, absolute system tick time on the event list has already expired. In this case, zero delay event may be added after the expired system tick event and no reschedule is performed (because the head of the list has not changed). Interrupt also didn't fire yet since it has been delayed, so after return from attach_callback(0) we are still waiting for the delayed interrupt and zero delay callback has not been called instantly.

This may also affect other platforms which use such delays (Cypress, NORDIC, etc.).

The proposition is to add extra condition while adding an event to the event list. If the inserted event is already expired, then perform reschedule immediately.