Remove Tickless from STM32F4 targets

[ABOSTM]

Description

Tickless on STM32 F4 boards causes SPI issue with following PR:

11682 Make FPGA tests to pass on CI targets (SPI, analogIn, PWM)

In asynch mode, using interrupts, SPI hardware detect an RX overrun.
Our understanding is that lpticker wrapper latency
causes issue similar to #8714 and #9785,
specially with SPI asynch which uses interrupts.

Pull request type

[ ] Fix
[ ] Refactor
[x ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[jeromecoutant]

@ARMmbed/team-st-mcd

[jeromecoutant]

FYI: @kjbracey-arm

[LMESTM]

Our understanding is that lpticker wrapper latency
causes issue similar to #8714 and #9785,

@bulislaw shouldn't the wrapper be discarded and removed sooner or later ?

[ciarmcom]

@ABOSTM, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[0xc0170]

So even tickless with using us ticker does not help. F4 then gets no tickless support?

The problem with SPI is captured here (PR referenced above): 6d25704 . Isn't there any other solution to this problem?

[mprse]

I understand that NUCLEO_F411RE board uses RTC to drive lp ticker and additionally the lp ticker wrapper is also enabled (boards that use LPTIM have low-level lp-licker wrapper to handle hardware limitations).

@ABOSTM I checked your proposition and run the fpga-spi test with MBED_TICKLESS disabled and can confirm that the test passes.

I understand that when MBED_TICKLESS is enabled, then the system tick is driven by lp-ticker (not sys-tick). The lp-ticker ISR execution takes too long and breaks the async SPI transfer since SPI ISR which handles received data is waiting until lp-ticker ISR is finished.
We might consider increasing the SPI interrupt priority. But even this might not help since most of the ticker ISR code is executed in the critical section.

[LMESTM]

So even tickless with using us ticker does not help. F4 then gets no tickless support?

Oh it would probably help. But using tickless from us ticker does not provide significant power saving, I find this very misleading for users that don't understand why there is no deep_sleep in the end.

The problem with SPI is captured here (PR referenced above): 6d25704 . Isn't there any other solution to this problem?

Disabling SPI async is not a solution, it's just hiding the problem. Disabling LP the wrapper as proposed here is the best way to remove the undesired ~100us system latencies.
So this PR allows to abandon or revert 6d25704

[LMESTM]

We might consider increasing the SPI interrupt priority. But even this might not help since most of the ticker ISR code is executed in the critical section.

@mprse That's right. We've tried that and could not succeed because the critical section may be too long anyway so increasing priority is not enough.

[mprse]

@LMESTM You have added the low-level-lp-ticker wrapper extension to targets which run lp-ticker using LPTIM. Would it be possible to add the same support for targets that run lp-ticker using RTC?

[LMESTM]

@LMESTM You have added the low-level-lp-ticker wrapper extension to targets which run lp-ticker using LPTIM. Would it be possible to add the same support for targets that run lp-ticker using RTC?

@mprse I'm not in favour of such development. Here are the reasons:

• LPTIM low level wrapper was complex but it makes sense as LPTIM is meant for this kind of use case.
• doing the same on RTC would require a lot of efforts, but would become even more complex when you start using RTC as a plain RTC (get_time / set_time) in parallel of using it as a low level LP ticker. That could quickly become a nightmare ... I don't want to get into this.

I would rather think of having a clear split:

• platforms with LPTIM can support tickless with low level wrapper
• platform without LPTIM should rather do tickless from µs. For low power and deep sleep support on those platforms: RTC alarm can be introduced and system can be suspended when system wants to enter deep sleep for relatively long periods of sleep and be woken-up from RTC alarm. This may be offered to application layer. Whether scheduler itself can benefit of this is open.

[0xc0170]

@ABOSTM @LMESTM How we can progress here, it's not clear to me based on the latest comment above.

[bulislaw]

Guys sorry for being late to the party as usual.
I agree that driving tickless from US ticker is the worst possible solution as it doesn't give us anything and makes wrong impression of the capabilities or state of the system.

As I can see it we have couple of possible ways forward:

• Disable tickles, and:
  • Do nothing 😞
  • Introduce well defined manual sleep mode with RTC alarm wakeup
• Rework tickless so that it can use multiple clocks reliably. Short-cut here could be that for targets that don't support LP ticker we could use systick with shallow sleep for sleep time below some threshold and swap to RTC alarm for longer times. That leaves big question about accuracy and drift open.

Ofc the complexity grows there, but I think going towards manual sleep with RTC wakeup first and possibly experimenting with the automatic option could be a good plan.

[LMESTM]

I agree with the steps recommended by @bulislaw
In short term, this means this PR can consist in disabling tickless.

[0xc0170]

@LMESTM lets rebase this one and proceed

[ABOSTM]

Rebase done.

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_greentea-test

[ABOSTM]

Hi @0xc0170 ,
Looking at log, I found that failed test is: 'tests-mbed_hal-sleep_manager'
But I execute the test on my side and it is working fine.
I even add some extra compilation switch (that Jerome get from you) to be as close as possible to CI tests: -DMBED_HEAP_STATS_ENABLED=1 -DMBED_STACK_STATS_ENABLED=1 -DMBED_TRAP_ERRORS_ENABLED=1 -DMBED_ALL_STATS_ENABLED -DMBED_CPU_STATS_ENABLED=1

Tests is still passed on my side.

[0xc0170]

I restarted the test, might do 2x.

@ABOSTM can you also test the binaries that are in the artifacts ? Download the same binary that test failed and rerun locally