Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low power timer needs to be reset when setting time #7849

Merged
merged 2 commits into from
Nov 8, 2018
Merged

Low power timer needs to be reset when setting time #7849

merged 2 commits into from
Nov 8, 2018

Conversation

TacoGrandeTX
Copy link
Contributor

Description

This PR addresses #7804.

When set_time() is called with DEVICE_LPTICKER the timer needs to be reset also, otherwise
the old _start value is incorrect and this taints the value returned by Timer::read().

Using the issue's test program, the minutes and seconds are now properly tracked after calling set_time():

resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018
Thu Aug 16 23:01:04 2018
Thu Aug 16 23:01:05 2018
Thu Aug 16 23:01:06 2018
Thu Aug 16 23:01:07 2018
Thu Aug 16 23:01:08 2018
Thu Aug 16 23:01:09 2018
Thu Aug 16 23:01:10 2018
resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018
Thu Aug 16 23:01:04 2018
Thu Aug 16 23:01:05 2018
Thu Aug 16 23:01:06 2018
Thu Aug 16 23:01:07 2018
Thu Aug 16 23:01:08 2018
Thu Aug 16 23:01:09 2018
Thu Aug 16 23:01:10 2018
resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

@TacoGrandeTX
Copy link
Contributor Author

Adding @kegilbert for comment/review

Copy link
Contributor

@kegilbert kegilbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, needs someone closer to the lpticker source to sign off though. Added @c1728p9 . Feel free to add anyone else.

@TacoGrandeTX TacoGrandeTX changed the title Low power timer needs to be reset when setting time. Low power timer needs to be reset when setting time Aug 21, 2018
@cmonr
Copy link
Contributor

cmonr commented Aug 22, 2018

@NeilMacMullen Would you mind confirming that this fixes the issue?

@0xc0170 0xc0170 requested a review from a team August 22, 2018 08:13
@0xc0170
Copy link
Contributor

0xc0170 commented Aug 22, 2018

@TacoGrandeTX Review travis failure, seems like this change fails to build

@NeilMacMullen
Copy link
Contributor

@cmonr Unfortunately I'm on vacation for the next couple of weeks so can't confirm for a while but I think the original issue report should make a reasonable unit test.

Copy link
Member

@bulislaw bulislaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need tests to confirm the fix.

RobMeades added a commit to u-blox/mbed-os that referenced this pull request Sep 5, 2018
…you just end up adding to the time instead of setting it.

ARMmbed#7849
@RobMeades
Copy link
Contributor

Can this fix be progressed please? It's not good to have something as fundamental as set_time() broken for so long.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 5, 2018

@TacoGrandeTX Can you please add a test case ?

@TacoGrandeTX
Copy link
Contributor Author

Neil MacMullen's test case is a good one:

#include "mbed.h"

int main()
{
    for (int hour = 23; hour >= 0; hour--)
    {
        for (int z = 0; z < 12; z++)
        {
            printf("resetting time using hour %d...\n", hour);

            struct tm t
            {
            };
            t.tm_year = 2018 - 1900;
            t.tm_mon = 8 - 1;
            t.tm_mday = 16;
            t.tm_hour = hour;
            t.tm_min = 1;
            t.tm_sec = 1;
            set_time(mktime(&t));

            for (int c = 0; c < 10; c++)
            {
                time_t seconds = time(NULL);
                printf("%s", ctime(&seconds));
                wait_ms(1000);
            }
        }
    }
    return 0;
}

Before (note how seconds are not reset):

resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018
Thu Aug 16 23:01:04 2018
Thu Aug 16 23:01:05 2018
Thu Aug 16 23:01:06 2018
Thu Aug 16 23:01:07 2018
Thu Aug 16 23:01:08 2018
Thu Aug 16 23:01:09 2018
Thu Aug 16 23:01:10 2018
resetting time using hour 23...
Thu Aug 16 23:01:11 2018
Thu Aug 16 23:01:12 2018
Thu Aug 16 23:01:13 2018
Thu Aug 16 23:01:14 2018

Now (seconds are reset after calling set_time()):

resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018
Thu Aug 16 23:01:04 2018
Thu Aug 16 23:01:05 2018
Thu Aug 16 23:01:06 2018
Thu Aug 16 23:01:07 2018
Thu Aug 16 23:01:08 2018
Thu Aug 16 23:01:09 2018
Thu Aug 16 23:01:10 2018
resetting time using hour 23...
Thu Aug 16 23:01:01 2018
Thu Aug 16 23:01:02 2018
Thu Aug 16 23:01:03 2018

Tested this on nRF52_DK and also MAX32620FTHR as there was a community post like RobMeades' about set_time() not working more than once on that target.

@cmonr
Copy link
Contributor

cmonr commented Sep 6, 2018

@TacoGrandeTX Something looks odd with this PR's history. Could you take a look at it?

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 6, 2018

@TacoGrandeTX What @bulislaw requested, we have hal tests for RTC. If new test case could be added to check to confirm the fix

@TacoGrandeTX
Copy link
Contributor Author

I've just created #8094 as a HAL test case.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 17, 2018

I've just created #8094 as a HAL test case.

To my understanding the test case should be part of this PR ? Otherwise test case PR cant be tested (fails). Can you add a test to this PR?

@TacoGrandeTX
Copy link
Contributor Author

@0xc0170 Understood - I've brought the HAL test into this PR and have closed #8094.

@kegilbert
Copy link
Contributor

@kjbracey-arm Has a good point, RTC->RTOS->LPTICKER->None sounds pretty solid to me.

Should be fairly straight forward to add that ordering here: https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_rtc_time.cpp#L25-L74

@TacoGrandeTX
Copy link
Contributor Author

@cmonr:

If RTC is off, then how are the current tests being run against any device?

As @kjbracey-arm pointed out, the tests in mbed_hal/rtc_time are only testing _rtc_maketime() and _rtc_localtime() which don't rely on having a running clock!

@kjbracey-arm:

Maybe the new test should have gone into "mbed_drivers/rtc", where the other time() tests are.

I think I'm going to have to do that. Thanks for pointing out the proper location. I'll try this again.

However, I would really like the time() call to work on those platforms. It would be good to have an alternative implementation for RTOS using Kernel::get_ms_count(), which means it would.

Like events now do, it's better to ask the RTOS for the time it already has than to have a separate timer, so I'd have it in precedence order "RTC->RTOS->LPTICKER->nothing".

OK - I'll check with @kegilbert about raising a new issue for this.

@kegilbert
Copy link
Contributor

@TacoGrandeTX Yeah a new issue would be perfect, sorry should've clarified that as an aside and not blocking for this PR.

RFulchiero added 2 commits November 1, 2018 17:11
Reset _rtc_lp_timer only if DEVICE_LPTICKER is defined.
When DEVICE_LPTICKER is defined set_time() only works correctly on
the first call. This test calls set_time() twice and ensures the
time set by both calls is correct.  This test only runs if
DEVICE_RTC or DEVICE_LPTICKER is defined.
@TacoGrandeTX
Copy link
Contributor Author

Met with @studavekar yesterday and he advised protecting the test with #if, so that's been done. Performed a merge to pick up the template test changes so this should now be good to go.

@studavekar
Copy link
Contributor

We need to revisit 6d90c27 and check if we can enable RTC on disabled devices.

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 6, 2018

We need to revisit 6d90c27 and check if we can enable RTC on disabled devices.

Who's doind this action? Is this blocking this PR?

@studavekar
Copy link
Contributor

Who's doind this action? Is this blocking this PR?

enablement RTC on disabled devices is not blocking this PR.

@cmonr
Copy link
Contributor

cmonr commented Nov 6, 2018

@studavekar Mind creating an issue? The comment made it sound like this needed to be addressed in this PR.

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 7, 2018

This is now entering CI

/morph build

@mbed-ci
Copy link

mbed-ci commented Nov 7, 2018

Build : SUCCESS

Build number : 3571
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7849/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Nov 7, 2018

@cmonr cmonr assigned cmonr and unassigned cmonr Nov 8, 2018
@cmonr cmonr added the rollup PR label Nov 8, 2018
@mbed-ci
Copy link

mbed-ci commented Nov 8, 2018

@cmonr
Copy link
Contributor

cmonr commented Nov 8, 2018

Note: This PR is now a part of a rollup PR (#8675).

Jenkins CI export nodes experienced many drops throughout the day causing false failures. In an attempt to get those PRs through CI, while keeping CI load low, several PRs have been bundled into a single rollup PR.

If any more commits are made in this PR, this PR will remain open and have to go through CI on its own.

@0xc0170 0xc0170 mentioned this pull request Nov 8, 2018
@0xc0170
Copy link
Contributor

0xc0170 commented Nov 8, 2018

/morph test
/morph export-build

@mbed-ci
Copy link

mbed-ci commented Nov 8, 2018

@mbed-ci
Copy link

mbed-ci commented Nov 8, 2018

@cmonr cmonr removed the rollup PR label Nov 8, 2018
@cmonr cmonr merged commit e635613 into ARMmbed:master Nov 8, 2018
@cmonr cmonr removed the needs: CI label Nov 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.