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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related