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

Problems with enabling softdevice while in DFU

Hi,

We are developping an app using nrf52840. We started with the SDK14.2 and needed to migrate to SDK15.0 in order to use the long range. We are also using a Bootloader and DFU in order to update the app Over The Air.

The app was migrated successfully and everything works as expected. The problem is with the bootloader project. Since the project was pretty empty we copied directly the secure bootloader ble exemple from the SDK15.0. After adjusting the flash and ram placements the bootloader project worked - as in: it started the main app. When our app activates DFU and performs a NVIC_SystemReset(); the bootloader starts, and recognize that we want to go in DFU. Everything looks ok until the bootloader reaches the function nrf_dfu_transports_init. In this function it recognizes that there is one transport and ble_stack_init() is called. The vector table is set correctly and nrf_sdh_enable_request(); is called. In this function we reach sd_softdevice_enable and then the device hangs. This functions doesn't return at all. We are then reset by the watchdog after about 90 seconds and the device does not enter DFU since it was reset and the flag has been cleared.

After reading other questions and answer on the subject I saw that the SoftDevice clock configuration in sdk_config.h was wrong, since it used the xtal crystal but there aren't any on my custom board. So I changed the setting to use these parameters:

//==========================================================

// <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

Now when I try to enter DFU the device resets right away. I use SEGGER_RTT_PRINT to debug and since there is a little delay with the printing it is kind of hard for me to know exactly where the system resets but I'm pretty sure that it reaches sd_softdevice_enable and that it is at this point that we reset.

I also saw that the problem may be linked to the memory layout. Here is the layout of my complete merged .hex file:

And here are the settings of my bootloader project:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0xf7000
FLASH_SIZE=0x7000
RAM_START=0x200022b0
RAM_SIZE=0x3dd50

And of my main application project:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0x26000
FLASH_SIZE=0xda000
RAM_START=0x200022b0
RAM_SIZE=0x3dd50

Best Regards

Parents
  • Hi,

    The way I understand, the bootloader runs but something happens when it calls sd_softdevice_enable(). Since the bootloader runs this means that much of the memory layout is OK. At least the bootloader is located where it should be (indicated in UICR), and it is started by the MBR (first page - part of the SoftDevice .hex). Since the error occurs when you make the first SoftDevice call, I wonder if perhaps you have the wrong SoftDevice flashed? Can you confirm that the SoftDevice which is flashed on the board is the same SoftDevice version you used when building the bootloader? If not, the SoftDevice API will be incompatible an anything could happen. It is important that you always update the SoftDevice and bootloader simultaneously. If there is a API mismatch, you will get problems.

  • In my bat files that merges my bootloader softdevice and application in one .hex file the softdevice used is: 

    SET SOFT_DEV=..\..\components\softdevice\s140\hex\s140_nrf52_6.0.0_softdevice.hex

    In my application project settings, the softdevice path is the following:

    The bootloader project comes from the SDK15 directly and the version of the softdevice in the SDK is the following:

    So I'm pretty sure that the softdevice version is the same all throughout if I'm not mistaken

  • I see, then most things should be good. Can you check with a debugger what happens when you say the system "hangs"? What state is the system in? Is an error check hit? Is it a hard fault? Etc?

    Without knowing more, another possible issue is if your bootloader RAM configuration leaves too little RAM for the SoftDevice. If you are using an unmodified bootloader, then you can use the RAM start address and size from the example bootloader project. If you have made modifications, you could increase the bootloader RAM start address (and reduce the size accordingly) a bit to make additional room for the SoftDevice. Then you can reduce it again later when you know how much RAM it needs for your configuration.

  • The bootloader project only has a release build configuration. I tried to add a debug configuration but I get these errors:

    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .text is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .dfu_trans is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .svc_data is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .sdh_ble_observers is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .sdh_req_observers is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .sdh_state_observers is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .sdh_stack_observers is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .sdh_soc_observers is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .fs_data is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .rodata is too large to fit in FLASH memory segment
    1> C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.22/gcc/arm-none-eabi/bin/ld: error: .data is too large to fit in FLASH memory segment

    From what I've gathered it seems there is not enough place to add the debug with my configurations... I'm not so sure on what to do now. (optimisation set to "Optimise for Size")

    For the RAM, I tried using the exact same settings from the exemple and I get the same problem. I also tried changing it like you said without success.

  • Hi,

    Yes, that is correct. The bootloader size increases when you add debug logging. Therefore, the SDK contains dedicated bootloader debug projects (e.g. <SDK15>\examples\dfu\secure_bootloader\pca10056_ble_debug), which has a lower bootloader start address to accommodate the larger bootloader. You would typically not use this in productions, but it is very useful when debugging bootloader and/or DFU issues.

Reply
  • Hi,

    Yes, that is correct. The bootloader size increases when you add debug logging. Therefore, the SDK contains dedicated bootloader debug projects (e.g. <SDK15>\examples\dfu\secure_bootloader\pca10056_ble_debug), which has a lower bootloader start address to accommodate the larger bootloader. You would typically not use this in productions, but it is very useful when debugging bootloader and/or DFU issues.

Children
Related