[STM32F0xx] LowPowerTicker implementation

[BartSX]

LowPowerTicker for STM32F0xx family is implemented using the RTC periodic unit
functionality. For more informations please follow this document:

• www.st.com/resource/en/application_note/dm00025071.pdf

Supported platforms:

• NUCLEO_F072RB
• NUCLEO_F070RB
• NUCLEO_F091RC

[0xc0170]

https://github.com/mbedmicro/mbed/blob/master/hal/hal/lp_ticker_api.h#L56

This should return current counter. how does it work for a use case like:

start = lp_ticker_read();
while (start + 10000 < lp_ticker_read()) { 
  sleep(); 
}

[0xc0170]

Please run lp ticker test and share the results

[bcostm]

I can't find the lp ticker test. Which one is it ?

[BartSX]

Hi,

@bcostm,
it's in the libraries/tests/utest/lp_ticker directory

@0xc0170,
thanks for the review and yes, you are right, that's why I've added the explanation comment. Currently that test will fail but we have modified MBED_11,23,24 and 25 to check the LowPowerTicker functionality and it works. Please the result below.

NUCLEO_F091RC
MBED_11	Pass
MBED_23	Pass
MBED_24	Pass
MBED_25	Pass

NUCLEO_F070RB
MBED_11	Pass
MBED_23	Pass
MBED_24	Pass
MBED_25	Pass

NUCLEO_F072RB
MBED_11	Pass
MBED_23	Pass
MBED_24	Pass
MBED_25	Pass

Also, I will try to figure out something tomorrow, if we can return the periodic unit counter value, because that unit is doing all the counting by it self and that's why I'm cheating mbed.

[0xc0170]

Yes ,it's https://github.com/mbedmicro/mbed/blob/master/libraries/tests/utest/lp_ticker/lp_ticker.cpp, using cpputest . I would say this test should fail for this implementation. If it is not, we should fix the test, and then this implementation.

I would expect to be able to read the timer's counter, in this case RTC (might be required some computation to do).

[0xc0170]

Any update? There are multiple pull requests with the same issue

[BartSX]

Hi @0xc0170,

I will update you late afternoon. Thanks.

[bcostm]

@0xc0170,
The lp counter value can't be returned because there is no CNT register in the RTC peripheral.

[0xc0170]

@bcostm I remember reading this a while back : http://stm32f4-discovery.net/2014/07/library-19-use-internal-rtc-on-stm32f4xx-devices/ , you can read time from RTC and convert that at least to milliseconds (subseconds) ?

[BartSX]

@0xc0170 All right but what about microseconds? I can't really agree with your quick proposal because the Wake-Up unit, which is almost in all STM's is designed to wake the device after some time amount. The range is from 122us to even 97days and all the calculation is done inside it, that's why there is no CNT register available in RTC peripheral. As I saw it, in ticker_api.c the desired value which you are appealing to (from lp_ticker_read()) is only used for calling the irq_handler or setting the interrupt. Our solution is handling that fine but when we will go one step further and think about the upper part of mBed the user will lose the possibility to read the actual time from LoPowerTimer.cpp (inherited from Timer.ccp).

We need to find a compromise, either we want to have the LowPowerTicker functionality or give the user ability to read the counter value from LowPowerTimer modules. From my perspective and what I'd like to have in mBed is the ability to attach my callback and put the device into sleep mode - period.
Due to that, I think it's not good that the user has the ability to include i.e. the lp_ticker_api.h in his/hers project because as I thought only CPP classes should be available for the user.

Thanks.

[0xc0170]

All right but what about microseconds?

You can't expect microseconds from the lp ticker, that is not possible in all cases. It was chosen to be microseconds to be compatible with us ticker API.

I can't really agree with your quick proposal because the Wake-Up unit, which is almost in all STM's is designed to wake the device after some time amount.

Why ? You can't read RTC time and convert it to milliseconds? I am not familiar with RTC unit in the STM32 chips, I am just missing details why it is not possible. I find it hard to believe I can't use read the time from RTC unit, when I see there's subseconds in the reference manual. Please provide details.

What we did for instance for K64F for another version of lp ticker, we combinted 2 low power timers , RTC to read seconds, and lower units, up to 0xffff milliseconds, from another timer. A hybrid.

As I saw it, in ticker_api.c the desired value which you are appealing to (from lp_ticker_read()) is only used for calling the irq_handler or setting the interrupt.

Yes, it might be this use case, but API is defined for read() to return current counter. And we can see LowPowerTimer uses this function to return current time.

Please state any shortcomings like this in the commit message for future.

[Sissors]

Why not just use the implementation that is used here: https://developer.mbed.org/users/Sissors/code/WakeUp/file/49ca85e8822f/Device/WakeUp_STM_RTC.cpp

It works also on the F030 and similar ones. The periodic unit one is not implemented on those. It simply uses instead of the periodic unit, the regular RTC. With the subseconds register you can get (not completely surprising), subsecond resolution. Since there I don't tamper with the mbed RTC settings i get around 3ms resolution. However by changing some settings in the RTC you can get 1/32000 resolution. (At the cost of a bit more current consumption in deepsleep, but I don't think it is that much). By setting the alarm to the correct time you can wake up after a certain amount of time has passed.

Only real obstacle I see: If someone changes the RTC time, it also changes the LowPowerTimer time.

[BartSX]

Hi @0xc0170,

You can't expect microseconds from the lp ticker, that is not possible in all cases. It was chosen to be microseconds to be compatible with us ticker API.

Even when we will put the compatibility aside, now with the RTC periodic unit we can reach us.

Why ? You can't read RTC time and convert it to milliseconds?

That we could do but we've wanted to use a dedicated unit to wake up the platform. So I think that we need to focus on actual implementation.

Please tell me what's more important for you. Is it the actual read counter value or is it the actual test pass? Because when you will run (or take a look) a utest/lp_ticker.cpp test (specifically the lpticker test, we are not talking about us_ticker group tests), it passes. I've checked that today and after obj->attach() our RTC unit will fire the interrupt after the desired value. In that unit our counter value is auto-reloaded that's why I'm returning the m_timestamp.

Please state any shortcomings like this in the commit message for future.

Will do so in future

Thanks

[0xc0170]

Please tell me what's more important for you. Is it the actual read counter value or is it the actual test pass? Because when you will run (or take a look) a utest/lp_ticker.cpp test (specifically the lpticker test, we are not talking about us_ticker group tests), it passes. I've checked that today and after obj->attach() our RTC unit will fire the interrupt after the desired value. In that unit our counter value is auto-reloaded that's why I'm returning the m_timestamp.

Both are. The tests shall be fixed, lp_ticker_read() should be tested that it increases properly. without invoking any other API within lp_ticker. We will fix the tests (rather said, we will write functional lp ticker tests).

Can you please add RTC read functionality into lp_ticker_read() ? To conform the API.

[BartSX]

Hi @0xc0170 and @bcostm,

I've added (changed almost everything) the read functionality. What is does it gets the time, sub-seconds and converts it into a timestamp value.
This is only for review, please do not merge yet because with those current prescalers we are able to get the min time -> 30ms.

[bcostm]

@0xc0170 is this implementation ok for you ?

[BartSX]

Hi @0xc0170 and @bcostm,

I've updated this PR and now the min time is 2ms, we can't reach 1ms and due to that it's 100% that we will not pass UT_LPTICKER test. I find that really strange, because with the initial implementation we were able to get the 1ms time using internal hardware wake-up unit but that did not followed your architecture.
Please review and in any questions feel free and ask.

[0xc0170]

Are there any problems with the lp ticker tests? If with this 2ms min resolution, it passes or ?

The implementation looks fine to me, please rebase to resolve conflicts

[BartSX]

Hi @0xc0170,
I've rebase the code. It's passing the compilation.

One more thing that I'd like to add. There are two cases that I would like to cover here:

1. We can only run the UT_LPTICKER tests with sleep() function. We can't wake up from deepsleep(), so this small change was made.
2. For some reason when we run the test with 2ms we able to meet the desired target. lp_ticker_read() is returning 3ms. However when we run the lp_ticker example and check the signal in logic analyzer, we are getting a 1.95ms period.

[0xc0170]

We can only run the UT_LPTICKER tests with sleep() function. We can't wake up from deepsleep(), so this small change was made.

What are the limitation of the deepsleep ? The lp ticker should be able to wake up from the deepsleep. That's the only timer it could do it.

[bcostm]

mbed sleep = stm32 sleep mode --> wakeup by any interrupt
mbed deepsleep = stm32 stop mode --> wakeup by external interrupt line only (EXTI). The RTC is not able to wakeup in this case

A solution would be to use stm32 standby mode instead for the deepsleep... this has to be checked because I don't remember why it was not done originally.

[Sissors]

The RTC is connected to an EXTI input internally. See also: https://developer.mbed.org/users/Sissors/code/WakeUp/file/49ca85e8822f/Device/WakeUp_STM_RTC.cpp. There I use the RTC alarm interrupt to wake it up from deepsleep, works fine.

[0xc0170]

please add a copyright header as other files have, thanks

[BartSX]

Ok. Thanks

[0xc0170]

Looks fine to me, just that one file without the copyright header.

[bcostm]

@BartSX, did you try to connect RTC to EXTI as done by @Sissors in his library and check if the test is ok ?

[BartSX]

Hi,

@0xc0170,
I've added copyrights.

@bcostm,
Actually everything it's working fine. We are passing the test with deepsleep(). It looks like we had some internal issue. Also, the EXTI is being enabled in HAL library when you call HAL_RTC_SetAlarm_IT.

[bcostm]

ok good news 😄