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

Fix us_ticker for NRF52 series #6796

Merged
merged 1 commit into from May 7, 2018

Conversation

Projects
None yet
6 participants
@marcuschangarm
Contributor

marcuschangarm commented May 2, 2018

Description

Changed comparison function when setting ticker timeout to fix
tickers not set correctly.

Pull request type

[x] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

@marcuschangarm marcuschangarm force-pushed the marcuschangarm:fix-nrf52-tick branch from 435959d to 07503d9 May 2, 2018

Fix us_ticker for NRF52 series
Changed comparison function when setting ticker timeout to fix
tickers not set correctly.

@marcuschangarm marcuschangarm force-pushed the marcuschangarm:fix-nrf52-tick branch from 07503d9 to b8f22bb May 2, 2018

@marcuschangarm

This comment has been minimized.

Contributor

marcuschangarm commented May 3, 2018

@studavekar this might improve the lp_ticker_timeout problems we've been seeing.

@0xc0170

This comment has been minimized.

Member

0xc0170 commented May 3, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented May 3, 2018

Build : SUCCESS

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

Triggering tests

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

@0xc0170

0xc0170 approved these changes May 3, 2018

@0xc0170 0xc0170 added needs: CI and removed needs: review labels May 3, 2018

@studavekar

This comment has been minimized.

Collaborator

studavekar commented May 3, 2018

@0xc0170 @cmonr

we would need multiple morph test on this PR , to make sure if the fix actually works. Also, this would be on high priority as lp_timeout fails inconsistently for NRF52 devices causing a lot of PR to be re-triggered.

@mbed-ci

This comment has been minimized.

@mbed-ci

This comment has been minimized.

@0xc0170

This comment has been minimized.

Member

0xc0170 commented May 4, 2018

/morph test

@0xc0170

This comment has been minimized.

Member

0xc0170 commented May 4, 2018

I'll run today 2 more rounds (at least 3 test runs)

@mbed-ci

This comment has been minimized.

@marcuschangarm

This comment has been minimized.

Contributor

marcuschangarm commented May 4, 2018

/morph test

@mbed-ci

This comment has been minimized.

@studavekar

This comment has been minimized.

Collaborator

studavekar commented May 6, 2018

/morph test

@mbed-ci

This comment has been minimized.

@0xc0170 0xc0170 merged commit 5a77f42 into ARMmbed:master May 7, 2018

13 checks passed

AWS-CI uVisor Build & Test Success
Details
ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-mbed2-build build completed
Details
ci-morph-test test completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
travis-ci/astyle Passed, 582 warnings (+0 warnings)
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Passed, runtime is 8874 cycles (-1165 cycles)
Details
travis-ci/gitattributestest Local gitattributestest testing has passed
Details
travis-ci/littlefs Passed, code size is 10112B (+0.00%)
Details
travis-ci/tools Local tools testing has passed
Details

@marcuschangarm marcuschangarm deleted the marcuschangarm:fix-nrf52-tick branch May 10, 2018

@fkjagodzinski

I looked at this PR in reference to #6732 and found one thing worth clarifying.

uint32_t closest_safe_compare = common_rtc_32bit_ticks_get() + 2;
if ((int)(compare_value - closest_safe_compare) <= 0) {
uint32_t closest_safe_compare = RTC_WRAP(common_rtc_32bit_ticks_get() + 2);
if (closest_safe_compare - compare_value < 2) {

This comment has been minimized.

@fkjagodzinski

fkjagodzinski May 23, 2018

Member

I might have missed something, but if compare_value is equal to the current RTC ticks value, that is compare_value == common_rtc_32bit_ticks_get(), this condition will be false and an invalid value will be written to CC register. Was that intentional? That new condition might well be replaced with: if (compare_value + 1 == closest_safe_compare).

This comment has been minimized.

@marcuschangarm

marcuschangarm May 23, 2018

Contributor

I think you are right. It should have been <= 2 in the comparison. However, the new 5.9 tickers are about to land so I don't think we should fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment