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

use RTC as system clock for CC13X2/CC26X2 #19232

Merged
merged 4 commits into from Sep 19, 2019
Merged

Conversation

vanti
Copy link
Collaborator

@vanti vanti commented Sep 17, 2019

Add RTC timer driver for CC13X2/CC26X2, and use it instead of systick
as system clock. It is necessary to use this timer for power
management support, so that the system can exit from deep sleep upon
expiry of timeouts.

A couple of tests also need to be adjusted as a result of using this timer.

Add RTC timer driver for CC13X2/CC26X2, and use it instead of systick
as system clock. It is necessary to use this timer for power
management support, so that the system can exit from deep sleep upon
expiry of timeouts.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
The RTC on TI CC13X2/CC26X2 is a 32 KHz clock for which the minimum
compare delay is 3 ticks. When using it as the system clock, we need
to relax the upper bound to ensure the test succeeds.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Given the RTC is used for system clock, we need to plug its interrupt
to avoid an exception that would occur if it is left unhandled.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
@vanti vanti changed the title use RTC support as system clock for CC13X2/CC26X2 use RTC as system clock for CC13X2/CC26X2 Sep 17, 2019
Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

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

Driver looks pretty good to me. One nitpick about initialization state, which is fine as long as the reset process guarantees the counter value.

drivers/timer/cc13x2_cc26x2_rtc_timer.c Show resolved Hide resolved
@vanti
Copy link
Collaborator Author

vanti commented Sep 18, 2019

@galak Not sure why the checks are not finishing...

@nashif nashif closed this Sep 19, 2019
@nashif nashif reopened this Sep 19, 2019
@zephyrbot zephyrbot added area: Devicetree area: Timer Timer area: Boards area: Tests Issues related to a particular existing or missing test area: Kernel labels Sep 19, 2019
@zephyrbot
Copy link
Collaborator

zephyrbot commented Sep 19, 2019

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

Adding @vanti as an owner.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
@galak galak merged commit 79d626f into zephyrproject-rtos:master Sep 19, 2019
@vanti
Copy link
Collaborator Author

vanti commented Sep 19, 2019

Thanks for the help!

@vanti vanti deleted the rtc branch September 19, 2019 18:59
vanti added a commit to vanti/zephyr that referenced this pull request Oct 31, 2019
The SPI peripheral should be configured using the CPU clock speed and
not the system clock speed. This used to be fine because they were the
same before zephyrproject-rtos#19232, but now that the system clock is RTC-based (which
has a different frequency), we can no longer make that assumption.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
galak pushed a commit that referenced this pull request Nov 7, 2019
The SPI peripheral should be configured using the CPU clock speed and
not the system clock speed. This used to be fine because they were the
same before #19232, but now that the system clock is RTC-based (which
has a different frequency), we can no longer make that assumption.

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
vanti added a commit to vanti/zephyr that referenced this pull request Nov 8, 2019
The I2C peripheral should be configured using the CPU clock frequency
and not the system clock frequency. This used to be fine because they
were the same before zephyrproject-rtos#19232, but now that the system clock is
RTC-based (which has a different frequency), we can no longer make
that assumption.

Fixes zephyrproject-rtos#20480

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
galak pushed a commit that referenced this pull request Nov 11, 2019
The I2C peripheral should be configured using the CPU clock frequency
and not the system clock frequency. This used to be fine because they
were the same before #19232, but now that the system clock is
RTC-based (which has a different frequency), we can no longer make
that assumption.

Fixes #20480

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Boards area: Devicetree area: Kernel area: Tests Issues related to a particular existing or missing test area: Timer Timer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants