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: after disconnect, device doesn't go into sleep again #9276

Closed
bearsh opened this Issue Jan 7, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@bearsh
Copy link

bearsh commented Jan 7, 2019

Description

BLE_HeartRate example, release profile, advertising interval changed to 250ms: during advertising, the current consumption is about 76uA. Once connected the controller keeps alive (I don't know if that's normal) and draws a little more then 3.3mA. But once disconnected, it still draws 3.3mA. Furthermore the spike while sending the advertisement packet is much higher (around 9mA compared to 6.5mA).

Target: nrf52
Toolchain: arm-none-eabi-gcc v7.3.1
Tools: mbed-cli v1.8.3
Mbed OS: c966348 (HEAD, tag: mbed-os-5.11.1, origin/mbed-os-5.11) Merge pull request #9208 from ARMmbed/release-candidate

image

  1. 0s - Blue line (~0.9s): advertising
  2. Blue line (~0.9s) - Red line (~4.6s): connected
  3. Red line (~4.6s) - ...: advertising

Issue request type

  • Question
  • Enhancement
  • Bug
@ciarmcom

This comment has been minimized.

Copy link
Member

ciarmcom commented Jan 7, 2019

@ciarmcom ciarmcom added the mirrored label Jan 7, 2019

@bearsh

This comment has been minimized.

Copy link
Author

bearsh commented Jan 8, 2019

The same also happens if I set a advertising timeout. Once the timeout is reached, advertising stop but current consumption increases dramatically.

@TacoGrandeTX

This comment has been minimized.

Copy link
Contributor

TacoGrandeTX commented Jan 11, 2019

@bearsh Thanks for pointing this out and we noticed it ourselves while investigating #9093. We have shown that this is related to the CryptoCell 310 (CC310), and @pan- has an idea to resolve it. The higher current floor we observe related to using the CC310 (mentioned in #9093) needs to be re-evaluated.

@bearsh

This comment has been minimized.

Copy link
Author

bearsh commented Jan 14, 2019

thanks, applying the workaround from #9093 (comment) reduces the current consumption to the desired value.

@TacoGrandeTX

This comment has been minimized.

Copy link
Contributor

TacoGrandeTX commented Feb 6, 2019

@bearsh Are you content and can we close the issue?

@bearsh

This comment has been minimized.

Copy link
Author

bearsh commented Feb 11, 2019

@TacoGrandeTX I didn't do any testing on the latest release but once #9372 get merged the issue will be closed automatically, so I don't see any reason to close it. furthermore, as far as I got it, there's no proof that #9372 will really solve this issue, even with #9019 merged...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.