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

nrf52: HFXO is not turned off as expected #15817

Closed
tsvehagen opened this issue May 2, 2019 · 3 comments · Fixed by #15830
Closed

nrf52: HFXO is not turned off as expected #15817

tsvehagen opened this issue May 2, 2019 · 3 comments · Fixed by #15830
Assignees
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug

Comments

@tsvehagen
Copy link
Collaborator

tsvehagen commented May 2, 2019

Describe the bug
I want to enter a system on sleep mode to minimize power usage. When running, Bluetooth mesh is being used but before going to sleep with k_cpu_idle, I suspend or reset it with bt_mesh_reset or bt_mesh_suspend. The problem is that HFXO is still in use and so a low power state is not really possible.

When CONFIG_BT_CTLR_XTAL_ADVANCED=n, the HFXO is turned off as expected. m16src_ref is 1 and goes to 0 after mesh reset.

To Reproduce
Steps to reproduce the behavior:

  1. Build Zephyr with CONFIG_BT_CTLR_XTAL_ADVANCED=y
  2. Enable bt mesh using bt_enable, bt_mesh_init and bt_mesh_provision
  3. m16src_ref in drivers/clock_control/nrf_power_clock.c is now 2, not sure if this is correct
  4. Call bt_mesh_reset
  5. Read NRF_CLOCK->HFCLKSTAT to see that HFXO is still on (0x10001)
  6. Also m16src_ref is still 1 (ie one reference)

Expected behavior
In step 5 above I would expect HFXO to be off, HFCLKSTAT = 0x10000
In step 6 above I would expect m16src_ref to be 0

Impact
No way to enter a system on sleep mode with low power usage.

Environment (please complete the following information):

  • OS: Linux
  • Toolchain Zephyr SDK 0.10.0
  • Zephyr v1.14.0
@tsvehagen tsvehagen added the bug The issue is a bug, or the PR is fixing a bug label May 2, 2019
@jhedberg
Copy link
Member

jhedberg commented May 2, 2019

The description doesn't mention any specific sample, but I suppose tests/bluetooth/mesh_shell might be most convenient using the following shell commands (didn't try myself but it should cause the same APIs to be called):

mesh init
mesh provision 1 2
mesh reset

cvinayak added a commit to cvinayak/zephyr that referenced this issue May 3, 2019
Fix XTAL advanced feature by adding the missing
implementation to calculate and, retain or release the XTAL
clock source after a Bluetooth state or role is stopped.

Fixes zephyrproject-rtos#15817.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
backporting bot pushed a commit that referenced this issue May 3, 2019
Fix XTAL advanced feature by adding the missing
implementation to calculate and, retain or release the XTAL
clock source after a Bluetooth state or role is stopped.

Fixes #15817.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
carlescufi pushed a commit that referenced this issue May 3, 2019
Fix XTAL advanced feature by adding the missing
implementation to calculate and, retain or release the XTAL
clock source after a Bluetooth state or role is stopped.

Fixes #15817.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
nashif pushed a commit that referenced this issue May 3, 2019
Fix XTAL advanced feature by adding the missing
implementation to calculate and, retain or release the XTAL
clock source after a Bluetooth state or role is stopped.

Fixes #15817.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
nashif pushed a commit that referenced this issue Jun 11, 2019
Fix XTAL advanced feature by adding the missing
implementation to calculate and, retain or release the XTAL
clock source after a Bluetooth state or role is stopped.

Fixes #15817.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
@summer20100514
Copy link

@tsvehagen hi, after the patch do you get good power consumption result?

@tsvehagen
Copy link
Collaborator Author

@summer20100514 I assume you mean power consumption for some nRF52 device. TBH, I haven't measured the power consumption but I'm pretty sure you can expect to get what Nordic has specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants