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

use external 32MHz crystal

Hi, Nordic Engineers. Now, i use a external 32mhz crystal on my board. i have add code"NRF_CLCOK->XTALFREQ = 0X00", but the BLE radio seems not work. Led flick is ok. Why? Would you like to give some advice?

  • Try this instead:

    NRF_CLOCK->XTALFREQ &= 0xFFFFFF00;

    Are you sure you have the correct Loading Capacitors on the 32MHz crystal?

  • I am sure after setup the external crystal selection, the register XTALFREQ is "0x00" with keil debugger.

  • Hi David

    There are two registers with the name XTALFREQ, one in the CLOCK section and one in the UICR section. The purpose of the XTALFREQ in the CLOCK section is to select the high frequency crystal source, 16MHz or 32MHz. This has a reset value of 0xFF which makes the chip start the 16MHz clock by default. However, you can modify the default value in the UICR->XTALFREQ register before starting the application with the following:

    nrfjprog.exe --snr <your_jlink_debugger_serial_number> --memwr 0x10001008 --val 0xFFFFFF00
    

    This will make 32MHz crystal to be used by default instead of 16MHz crystal.

    Verify that UICR address 0x10001008 is written by reading the memory content with:

    nrfjprog.exe --snr <your_jlink_debugger_serial_number> --memrd 0x10001008 --n 16
    

    Or you can include code in your SystemInit function as Locky pointed out to start 32MHz crystal instead of 16MHz crystal, something like:

    NRF_CLOCK->XTALFREQ = 0xFFFFFF00;
    

    What is the value of your load capacitors? For info, look at sections 3.6.1 in the nRF51822 PS v3.1 and in table 23.

    Update 8.7.2015 For safe operation with 32MHz crystal, apply both of the above, i.e. write to UICR and to the NRF_CLOCK->XTALFREQ register.

    Note: The chip will use 16MHz clock frequency even though 32MHz crystal is chosen. The 32MHz input frequency is divided with two before applying it to the nRF51 peripherals.

    Update 14.1.2016 Also change the definition at the top of the system.nrf51.c file from

    #define __SYSTEM_CLOCK      (16000000UL)
    

    to

    #define __SYSTEM_CLOCK      (32000000UL)
    

    A normal application that does not use softdevice starts up using the 16MHz internal RC oscillator and does not use the external 16MHz/32MHz crystal unless it is explicitly enabled in the application code. When using softdevice, the external crystal is enabled during radio operation, as the radio requires accuracy of an external crystal. In order to test that the 32MHz crystal works you can enable it explicitly with the following code:

    int main(void)
    {
        // Set the external high frequency clock source to 32 MHz
        NRF_CLOCK->XTALFREQ = 0xFFFFFF00;
    
        // Start the external high frequency crystal
        NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
        NRF_CLOCK->TASKS_HFCLKSTART = 1;
    
        // Wait for the external oscillator to start up
        while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) {}
    
        while (true) { }
    }
    
  • We experienced similar behaviours on one of our evaluation boards. The reason for this was an quite old hardware revision of the chip on the board, where there was a known bug described in the Product Anomaly Notice nRF51822-PAN v2.0 on page 16. Maybe this helps.

  • Thanks for pointing this out. The anomaly is valid for nRF51 first revision. However, writing to UICR->XTALFREQ as described above is a valid workaround for that anomaly. The anomaly does however describe an alternative workaround where you can write to UICR->XTALFREQ from code.

Related