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.

Parents
  • 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 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?

Reply Children
No Data
Related