Hi Xiang,
can you confirm that arch_timer.c assumes that the timer resets itself? (as if
using STM32 autoreload?)
It doesn't call TIMER_STOP() on the underlying timer on timer_cancel(). In
fact, it simply sets a maximum timeout.
I understand this is because you also need the timer to be running to provide
up_timer_gettime().
If this is so, it would be incorrect to do this in stm32/nrf52_tim_lowerhalf.c
(I'm using it as reference):
static int stm32_settimeout(FAR struct timer_lowerhalf_s *lower, uint32_t
timeout)
{
FAR struct stm32_lowerhalf_s *priv = (FAR struct stm32_lowerhalf_s *)lower;
uint64_t maxtimeout;
if (priv->started)
{
return -EPERM;
}
...
(nRF52 has the same check on priv->started). This means that the settimeout
does not succeed.
On my nrf52_rtc_lowerhalf.c I have removed this check and I get tickless
working but this would mean
the same fix should be applied on other similar places. In principle this is OK
because changing the
timeout while timer is running should not be a problem.
Best,
Matias
On Thu, Sep 3, 2020, at 12:29, Matias N. wrote:
> Hi,
> thanks, I will select TIMER_ARCH from Kconfig for this arch for now. I can
> create an issue later.
> I will also try to document these three drivers and link them from the
> discussion about tickless support.
>
> Best,
> Matias
