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

nRF52 clock in and out

I have two related questions about nRF52 (nrf52832) which I have not been able to pinpoint from the documentation.

  1. Can the 32MHz crystal connection be replaced by a 32MHz input if there is an existing clock in the system that meets the precision, tolerance, etc? On many processors, one of the two crystal pins may be used as an input while the other is left open if there is a driven external source, but I see no information about this for nRF52.

  2. What is the most power-efficient way to get a high frequency clock output from the nRF52? Other ARM processors seem to offer direct "HFCLK" outputs to pins, but I can't find any related features in the nRF52 documentation. The best I've been able to guess is that the SPIM or PWM blocks could be used to provide a clock (8MHz or 16MHz respectively?) but each of those draws additional power and we don't (in this case) need the remaining functionality of the peripherals.

Thank you.

  • Hi,

    1. See Martin's answer.

    2. The peripherals only run at 16MHz, this is why it is not possible to get HFCLK output from the nRF52. Max output is 8MHz, since you need to toggle on and off a pin. This is achieved using GPIOTE and PPI with the following code which creates a 8MHz output on pin 18:

       int main(void)
       {
       nrf_gpio_range_cfg_output(18); //Configure pin 18 as output
      
       NRF_CLOCK->TASKS_HFCLKSTART = 1; //Start high frequency clock
       while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
       {
            //Wait for HFCLK to start
       }
       NRF_CLOCK->EVENTS_HFCLKSTARTED = 0; //Clear event
       
       
       //Configure GPIOTE to toggle pin 18 
       NRF_GPIOTE->CONFIG[0] = GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos |
                               GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos |
                               18 << GPIOTE_CONFIG_PSEL_Pos | 
                               GPIOTE_CONFIG_OUTINIT_Low << GPIOTE_CONFIG_OUTINIT_Pos;
       
       //Configure timer
       NRF_TIMER1->PRESCALER = 0;
       NRF_TIMER1->CC[0] = 1;  // Adjust the output frequency by adjusting the CC.
       NRF_TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Enabled << TIMER_SHORTS_COMPARE0_CLEAR_Pos;
       NRF_TIMER1->TASKS_START = 1;
       
       //Configure PPI
       NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
       NRF_PPI->CH[0].TEP = (uint32_t) &NRF_GPIOTE->TASKS_OUT[0];
       
       NRF_PPI->CHENSET = PPI_CHENSET_CH0_Enabled << PPI_CHENSET_CH0_Pos;
       
       while (true)
       {
           // do nothing
       }
       }
      

    Best regards,

    Øyvind

  • This is excellent information - I believe that 8MHz would work well for our needs. Is there any simple way to estimate of the power impact of the GPIOTE solution listed above? I assume it's more complex that just CfV^2 for the I/O pin.

  • Just to be clear, for my second point, it is fine that I can't get 32MHz or 64MHz out ("the high frequency clock"); the design simply requires some clock in the MHz range ("a high frequency clock") and the power drawn by the nRF52 is orders of magnitude lower than typical crystal oscillators drawing several mA. We just want to get the power as low as possible.

  • Well we have a pin capacitance of 4pF at each GPIO, the pulse moves at 8MHz and we know the relation X_C = 1/ ω C, this gives a equivalent resistance of approximately 5kΩ. Then you will have to add what you end up connecting to the pad. In the end the power consumed will be approximately equal to the power going through the equivalent resistor.

    Alternately you can set up this on your development kit and measure the difference in current draw with and without 8MHz output. Please refer to the current measurement guide for practical information.

  • The back-of-the-envelope is very helpful, since I don't have the tools to measure currents in the uA range at my immediate disposal. I was just wondering if the GPIOTE functions would contribute noticeable additional power draw - the data sheet only lists IGPIOTE,IN and doesn't give any info about frequency dependency (uA/MHz). If I assume a 1.8V supply and only consider the pad capacitance (data sheet says 3pF except for NFC, but I'll stick with your 4pF for consistency), your formula and the resulting 5kΩ gives about 360uA per pin. In contrast, the formula from the datasheet (pg. 151: IGPIO=VDD Cload f) gives about 58uA per pin. I'm not sure which of these is a better estimate, but they are rather different.

Related