This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High frequency clock operation on time slot API

I read the multi-role project on Github. For time slot part, there's no explicit hfclk start/stop operation along with the radio events, is it possible that sd_radio_session_open or some other function does it implicitly and automatically, or hfclk is just left opened always, however, which would incur the standby current consumption of 25uA as this thread mentioned.

Do you have any idea on this? Thanks.

  • Hi joc

    Thank you for your question.

    A hint to how this works is given in S110 Softdevice Specification 2.0, section 9.6.5 which states that TIMER0 is automatically started in 1MHz mode by the softdevice at the beginning of the timeslot.

    XTAL is always started when using the Timeslot API. When timeslots are requested with the NRF_RADIO_HFCLK_CFG_DEFAULT option, the XTAL is started at the same time as the timeslot START signal is given, unless it already runs. If the NRF_RADIO_HFCLK_CFG_FORCE_XTAL is used, the XTAL is started earlier if not already running, so that it is already running and stable when the timeslot START signal is given.

    The application is free to do whatever it likes to TIMER0 within the timeslot. Stop, start, reconfigure, etc. Having it running at 1MHz from start is just implemented as a convenience.

    HFCLK on the other hand, should not be touched by the application in the timeslot as there is some state kept in the softdevice about the HFCLK state.

    During a timeslot, I would expect the current consumption in a timeslot to be approximately the sum of the following two if you exclude any application activity in your timeslot:

    • 16MHz XTAL in 1MHz mode ; I_X16M,1M = 250uA, see table 22 in nRF51822 PS v3.1
    • TIMER0 ; I_TIMER0/1/2,1M = 4uA, see table 52 in nRF51822 PS v3.1

    If you however set prescaler of TIMER0 lower than 4 (higher frequency than 1MHz) then both the timer and the XTAL will consume more current, see the tables 22 and 52 in the PS. You could however choose to stop TIMER0 when entering the timeslot in order to save current of 4uA with

    NRF_TIMER0->TASKS_STOP = 1;
    

    If no other peripherals are running when stopping TIMER0, XTAL will enter standby mode with 25uA current consumption, see table 22 in nRF51822 PS v3.1

    The XTAL is always kept running at the beginning of the timeslot because it has lower current consumption than RC once it is started, and all peripherals need HFCLK. If you have nothing to do in the timeslot, just end it and then the HFCLK is automatically and immediately disabled after the end of the timeslot. If there is however another radio event starting shortly after the end of the timeslot, it might not pay off to disable the XTAL, and in that case the XTAL will enter standby mode instead.

  • Thanks for your answer, Stefan.

    For radio module requires HFCLK crystal source, if I choose HFCLK RC at the beginning of the time slot(if i can), does it mean both of the two different HFCLK source are enabled? Or your answer implies that the radio event of time slot API can only use the RC source while softdevice has to rely on the crystal source?

    While the time slot call back action of NRF_RADIO_SIGNAL_CALLBACK_ACTION_END would end the time slot session, does it stop the HFCLK XTAL instead of leaving it in the standby mode?

    And do you think it's resonable to mannualy stop/start the XTAL between the time slot to save current consumption if I choose XTAL at the beginning of the time slot?

    Thanks again for your help.

  • Hi joc

    While starting the crystal, the internal RC continues to provide the HFCLK to peripherals. When the crystal is fully enabled and ready to provide the HFCLK, the RC is shut down. When the crystal is disabled again, the RC is started again, but only if any peripheral is enabled that requires HFCLK.

    Since the softdevice requires the crystal to operate the radio, I suspect that it does not disable the crystal if the timeslot requires the crystal. If the timeslot requires the RC, it will shut disable the crystal, which will automatically start the RC if TIMER0 is enabled.

    I assume that the softdevice will restore the state of XTAL after the timeslot ends. I can not be certain however unless consulting with the softdevice team. I will add a comment on this thread when I have further information.

  • I updated my provided answer with both better and additional information on TIMER0/HFCLK properties in a Timeslot

  • Thanks for updating. It's better! So the action like NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END which ends the current timeslot for the signal callback would disable XTAL immediately unless there's another radio event short after, right?

Related