This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Production Support For NRF52832

We have our one of  Product Firmware of  NRF52832 written in the Keilv5.

As the Application use the Softdevice Functionality we need to load Softdevice code and Application code separately that makes the programming processes too much time consuming which affects on  our overall production time and for mass production that is quit impractical.we looking for the better for this from your side.

We need argent support and suggestion for the  above mentioned matter.

for Programming purpose we are using the segger j link, can we flash the code using mu-link or other j link ?

  • Hi,

    As the Application use the Softdevice Functionality we need to load Softdevice code and Application code separately that makes the programming processes too much time consuming

    You can merge the hex files together.

    You can use mergehex for that: https://infocenter.nordicsemi.com/topic/ug_nrf_cltools/UG/cltools/nrf_mergehex.html

    It's part of nRF Command Line Tools: 

    https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools/download

    BR,

    Sigurd

  • Thank You @Sigurd Olav Nevstad for your quick reply i will go through the mergehex and command line tool, if i have query  in further process i will back to you.

    i request you to guide me for Following 

    Using the LFSYNT clock avoids the requirement for a 32.768 kHz crystal, but increases average power
    consumption as the HFCLK will need to be requested in the system.

    Bu using which API can i do above mentioned action .

  • Hi,

    NarendrasinhDabhi said:

    Using the LFSYNT clock avoids the requirement for a 32.768 kHz crystal, but increases average power
    consumption as the HFCLK will need to be requested in the system.

    Bu using which API can i do above mentioned action .

    You should then use the internal LF RC oscillator instead. To use that as the clock source for the SoftDevice, make sure that you configure it like this in sdk_config.h

    Snippet:

    //==========================================================
     
    // <h> Clock - SoftDevice clock configuration
     
    //==========================================================
    // <o> NRF_SDH_CLOCK_LF_SRC - SoftDevice clock source.
    
    // <0=> NRF_CLOCK_LF_SRC_RC
    // <1=> NRF_CLOCK_LF_SRC_XTAL
    // <2=> NRF_CLOCK_LF_SRC_SYNTH
     
    #ifndef NRF_SDH_CLOCK_LF_SRC
    #define NRF_SDH_CLOCK_LF_SRC 0
    #endif
     
    // <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
    #ifndef NRF_SDH_CLOCK_LF_RC_CTIV
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #endif
     
    // <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
    // <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
    // <i> if the temperature has not changed.
     
    #ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #endif
     
    // <o> NRF_SDH_CLOCK_LF_ACCURACY - External clock accuracy used in the LL to compute timing.
    
    // <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
    // <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
    // <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
    // <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
    // <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
    // <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
    // <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
    // <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
    // <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
    // <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
    // <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
    // <11=> NRF_CLOCK_LF_ACCURACY_1_PPM
     
    #ifndef NRF_SDH_CLOCK_LF_ACCURACY
    #define NRF_SDH_CLOCK_LF_ACCURACY 1
    #endif

  • Thank you @Sigurd Olav Nevstad,

    your suggestion is working.

    NRF_CLOCK_LF_ACCURACY_x_PPM is making the what difference in performance? .

    can you elaborate something on that?

    Thank you.

  • Hi,

    NarendrasinhDabhi said:

    NRF_CLOCK_LF_ACCURACY_x_PPM is making the what difference in performance? .

    can you elaborate something on that?

    In a BLE connection, you get few extra µA current consumption draw.

    You can test it yourself with the Online Power profiler:

    https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-bluetooth-le

    PS: If you have new questions unrelated to the original question in this case, I recommend creating a new case for the new question: https://devzone.nordicsemi.com/support/add

    BR,

    Sigurd

Related