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

nRF52832 not starting after successful transfer using secure_dfu_ble_s132_pca10040 example

Hi,

I tried to make a software update (I tried application, bootloader, SoftDevice and any combinations) over BLE using the secure_dfu_ble_s132_pca10040 example but after the successful transfer the nRF52832 does not start any more.

In order to debug the error, I tried to enable the logs and therefor changed the following in sdk_config:

  • NRF_BALLOC_ENABLED 1
  • NRF_LOG_ENABLED 1
  • NRF_LOG_BUFSIZE 128

In order to compile the project, I had to include the following files in the project:

  • nrf_log_backend_uart
  • nrf_log_default_backends
  • nrf_log_fronted
  • nrf_log_str_formatter
  • nrf_balloc
  • nrf_memobj
  • nrf_fprintf
  • nrf_fprintf_format

I tried this example using nRF5_SDK_14.2.0_17b948a with IAR Embedded Workbench for ARM 7.70.2.11710 + IAR Embedded Workbench shared components 7.5.2.4549 and nRF5_SDK_14.1.0_1dda907 with IAR Embedded Workbench for ARM 8.11.1.13272 + IAR Embedded Workbench shared components 8.0.6.4851. I compiled the micro_ecc_lib using the nRF52 iar Makefile. I change the public key in the corresponding file and signed the zip file using the corresponding private key.

In both cases the nRF52832 does not start after the update and seems to stay in dfu mode without booting the application. If I press the button during the boot the previous firmware is starting. The versions are set properly and the debug version didn't work neither.

In both cases the example bootloader_secure_ble cannot be compiled with the LOGs enabled, so debugging is quite difficult. The error is: "unable to allocate space for sections/blocks with a total estimated minimum size of 0x73f5 bytes (max align 0x10) in <[0x00078000-0x0007dfff]> (total uncommitted space 0x5e00)."

My questions:

  1. How can I get the update working?
  2. How can I activate some debug function in order to find the problem?

Thank you for your help.

Best regards

  • Hi Olivier,

    Have you tried to update only the application ?

    You mentioned "If I press the button during the boot the previous firmware is starting." what does that mean ? How did you flash the previous firmware ?

    The error you have "unable to allocate space" meant the size of the bootloader exceed that configured size and location of the bootloader. In order to increase the allocated size for the bootloader, you need to move down the start address in the flash (because it's located at the top of the flag) in the project option in IAR (->Linker->Config ->Edit). Make sure you erase the chip after you change bootloader's start address.

  • Hi Hung,

    Thank you for your answer.

    Yes, I tried to update only the application, only the bootloader, only the SoftDevice and any combinations. I managed to update the SoftDevice several times (not always) but never the application.

    Yes, after the transfer the app says transfer successful and the chip reboot. When the chip reboot it does not advertise any more but if I press the button (probably the one you described in the dfu example to leave the dfu mode) during the boot the chip start using the old application.

    I flashed the first firmware after having fully erased the chip and programed the SoftDevice. To generate the first application, I compiled the example secure_dfu_ble_s132_pca10040 with iar. Then I used nrfutil

    "nrfutil settings generate --family NRF52 --application secure_dfu_ble_s132_pca10040.hex --application-version 0 --bootloader-version 0 --bl-settings-version 1 bootloader_settings.hex"

    and mergehex "mergehex -m secure_dfu_ble_s132_pca10040.hex bootloader_settings.hex -o nrf_bootloader_and_app.hex".

    After that I used nrfjprog "nrfjprog --reset --program s132_nrf52_5.0.0_softdevice.hex -f nrf52 --chiperase" and "nrfjprog --reset --program nrf_bootloader_and_app.hex -f nrf52".

    After that the chip send advertising packets and I can connect to it with the Nordic app using a tabled over BLE.

    For the update, I made some changes in the software and I used nrfutil "nrfutil pkg generate --hw-version 52 --sd-req 0x9D --application-version 1 --application secure_dfu_ble_s132_pca10040.hex --key-file private.pem app_dfu_package_new.zip" to generate a zip file which I uploaded in the tablet.

    I started the update with the Nordic app and successfully transferred the application.

    I will have a look at the bootloader size, but I changed nothing in your example except that I have activated the UART Logs, so it should work.

    Thank you for your help.

    Best regards.

  • Hi Orisen,

    Please try to follow my blog here and test first with an example in the SDK , for example ble_app_hrs. Please don't try mergehex at the first test.

    If you follow my blog and it still doesn't work, please attach your bootloader, application, private key, and the dfu.zip package.

  • Hi Hung,

    Thank you for your answer.

    Yes It seems that the problem comes from the mergehex. Without this step I was able to update the application.

    I was following the documentation at infocenter.nordicsemi.com/index.jsp point 4 which stats "If you generated a bootloader settings HEX file, use mergehex (part of the nRF5x Command Line Tools) to merge the bootloader HEX file and the bootloader settings HEX file." and I applied this for the application as well.

    Thank you for your help.

    Best regards.

Related