Problems with enabling softdevice while in DFU

RE: Problems with enabling softdevice while in DFU

Philemon — Mon, 28 Oct 2019 12:10:04 GMT

Nevermind,

By using the debug project I forgot that I had to change back my sdk_config file to use the RC oscillator. After doing that with this project I'm able to go into DFU. I don't know why the other project did not work but everything seems fine now.

Thank you very much for your help!

RE: Problems with enabling softdevice while in DFU

Philemon — Mon, 28 Oct 2019 12:01:31 GMT

Hi,

Ok, using the debug project I now know that after going into DFU from my main application I go in the bootloader, I get to ble_stack_init and then I get to sd_softdevice_enable and hangs there:

RE: Problems with enabling softdevice while in DFU

Einar Thorsrud — Mon, 28 Oct 2019 07:58:25 GMT

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.

RE: Problems with enabling softdevice while in DFU

Philemon — Fri, 25 Oct 2019 15:47:17 GMT

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.

RE: Problems with enabling softdevice while in DFU

Einar Thorsrud — Thu, 24 Oct 2019 08:35:55 GMT

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.

RE: Problems with enabling softdevice while in DFU

Philemon — Wed, 23 Oct 2019 18:43:59 GMT

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

RE: Problems with enabling softdevice while in DFU

Einar Thorsrud — Tue, 22 Oct 2019 12:50:36 GMT

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.