• State Not Answered
  • Replies 11 replies
  • Subscribers 74 subscribers
  • Views 245 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 343464
Options

When the clock source is LFRC then the device goes into high power state which is ~800uA

Gaurav

I have my application running (NCS 2.6.4) on the bench with clock source set as internal RC and with the configurations such as -

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD=5000
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_LF_ALWAYS_ON=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=10

But when I do multiple resets using nrfjprog --reset then the device goes into high power state which have the average current as ~800uA but the application runs normally and there is no issue in functionality.
When I switch the clock configuration to XTAL then the issue goes away which signifies there is some issue with the clock source and I am able to replicate the same state on the board with blinky example with the above clock configurations.

Any workaround which can solve this issue apart from changing the configuration to XTAL.

Parents
  • 0

    Hi,

    Is there a chance that the device is still in debug mode when you test this? In debug mode the device will not enter IDLE sleep but will emulate it. Debug mode is activated when the debugger is connected, and disconnecting the debugger is not enough to exit debug mode. Only a power on reset will 100% exit debug mode, although I would have expected pin reset to have similar result.

    regards
    Jared 

  • 0 in reply to Jared

     Yes the debugger was connected but the behaviour is very weird here as the device stays in high power state even in pin resets state.
    For this to debug I have added to note down ramp up time of HFXO and this value was coming as 1uS for this scenario. And when I DFU or flash application with XTAL configured then the issue goes away.

  • 0 in reply to Jared

    We have switched our clock reference to internal RC as the XTAL config was showing lot of issues on production and on field.

    We have tried to replicate this issue on the board that we have made custom and have been shipping this hardware from the last 2 years and never faced this issue and since we switched to internal RC and with the config shared above we are able to replicate this on bench.

    We have even tried this on sample/bluetooth/blinky and with the same clock config and that was also showing the same power drain of ~900uA.
    And to fix this issue if we do Power on Reset or changing the config to XTAL, it gets fixed.
    So certainly something is wrong with the clock configs where the internal RC on startup is not able to calibrate with the HFXO.
    This is how the power profile looks when the high power state gets triggered-



  • 0 in reply to Gaurav

    Hi,

    I tried to flash a development kit with the a BLE sample with the configs that you have shared but was not able to replicate the same result.

    Can you share a hex I can flex to my devkit to try to reproduce it?

    regards

    Jared 

  • 0 in reply to Jared

    SO after using the SWD interface for programming or/and debugging you should always power cycle the device before measuring current. This is needed as the debug interface on ARM devices can only be guaranteed to be disabled this way.

  • 0 in reply to PaKa

     I understand that part, after doing power cycle and without SWD interface if I push soft reset command using BLE command handler then also this state arises and gets solved again by power cycle but permanent solution is updating to a firmware which has external clock as clock ref in it.
    So issue doesnt look like the debugging interface but most likely the clock is behaving erratic.

     No on DK I am not able to reproduce with the same configs, but on my board even with sample examples I am seeing the high dissipation state.

  • 0 in reply to Gaurav

    Hi Gaurav,

    I still suspect that this issue is related to the chip not going into sleep mode due to debug mode. How this is correlates to your observation with LFCLK source is not clear.

    Do you have PPK2 that you can use to share a complete power trace with me that I can analyze? 

    Are you supplying any other external circuitry trough VDD from the nRF52840? 

    Here is an overview over the difference between soft reset and power-on-reset:

    Also, I don't think it's unreasonable to require a power cycle to be performed after you have flashed the nRF52840 with an external debugger. 

    regards

    Jared

Reply
  • 0 in reply to Gaurav

    Hi Gaurav,

    I still suspect that this issue is related to the chip not going into sleep mode due to debug mode. How this is correlates to your observation with LFCLK source is not clear.

    Do you have PPK2 that you can use to share a complete power trace with me that I can analyze? 

    Are you supplying any other external circuitry trough VDD from the nRF52840? 

    Here is an overview over the difference between soft reset and power-on-reset:

    Also, I don't think it's unreasonable to require a power cycle to be performed after you have flashed the nRF52840 with an external debugger. 

    regards

    Jared

Children
Related
Terms of service