Can a device flashed (with just softdevice and application) with Segger be dfu OTA afterwards?

Hi folks, thanks in advance for your support.

The thing is that in my SEGGER project I didn't have explicitly linked a bootloader to be flashed in the device (nRF52832), thus I don't know if the device has no bootloader, or it runs a standard bootloader that the softdevice chose. To add more fun I don't have physical connection to the device.  (attached compilation's output from SEGGER)

Building ‘my_project_fw’ from solution ‘my_project_fw’ in configuration ‘Release’
1> Output/Release/Obj/my_project_fw/thumb_crt0.o does not exist.
1> Assembling ‘thumb_crt0.s’
1> "C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 5.32/gcc/arm-none-eabi/bin/cc1" -fmessage-length=0 -fno-diagnostics-show-caret -E -mcpu=cortex-m4 -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -nostdinc "-isystemC:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 5.32/include" -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/ble_advertising -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/ble_services/ble_dfu -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/common -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/nrf_ble_gatt -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/nrf_ble_qwr -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/ble/peer_manager -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/atomic -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/atomic_fifo -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/atomic_flags -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/balloc -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/ble_dfu -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/dfu -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/delay -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/experimental_section_vars -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/fds -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/fstorage -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/log -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/log/src -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/mutex -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/pwm -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/pwr_mgmt -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/strerror -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/svc -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/timer -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/util -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/softdevice/s132/headers -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/toolchain/cmsis/include -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/softdevice/common -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/softdevice/s132/headers/nrf52 -I../../nordic/nRF5_SDK_17.1.0_ddde560/integration/nrfx -I../../nordic/nRF5_SDK_17.1.0_ddde560/integration/nrfx/legacy -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx/drivers/include -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx/hal -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx/drivers/src -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx/drivers/src/prs -I../../nordic/nRF5_SDK_17.1.0_ddde560/modules/nrfx/mdk -Iconfig -I../src -I../src/my_project_apps -I../src/my_project_config -I../src/my_project_controllers -I../src/my_project_drivers -I../src/my_project_libraries -I../src/my_project_system -D__SIZEOF_WCHAR_T=4 -D__ARM_ARCH_7EM__ -D__SES_ARM -D__ARM_ARCH_FPV4_SP_D16__ -D__HEAP_SIZE__=8192 -D__SES_VERSION=53200 -D__GNU_LINKER -DNDEBUG -DBOARD_PCA10056 -DBSP_DEFINES_ONLY -DCONFIG_GPIO_AS_PINRESET -DFLOAT_ABI_HARD -DINITIALIZE_USER_SECTIONS -DNO_VTOR_CONFIG -DNRF52 -DNRF52832_XXAA -DNRF52_PAN_74 -DNRF_DFU_SVCI_ENABLED -DNRF_DFU_TRANSPORT_BLE=1 -DNRF_SD_BLE_API_VERSION=7 -DS132 -DSOFTDEVICE_PRESENT -DSWI_DISABLE0 -MD C:/Users/JKPina_my_project/Desktop/git/my_project-Electrical-FirmwareCH02/project/Output/Release/Obj/my_project_fw/thumb_crt0.d -MQ Output/Release/Obj/my_project_fw/thumb_crt0.o -quiet -lang-asm "C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 5.32/source/thumb_crt0.s" -o C:/Users/JKPina_my_project/Desktop/git/my_project-Electrical-FirmwareCH02/project/Output/Release/Obj/my_project_fw/thumb_crt0_PP.s

My goal is to update the application's firmware wirelessly to the device. After first flashed through Segger, I run :
     nrfutil dfu ble -ic NRF52 -pkg .\app_valid_setting_apply_nRF52832_plus_softdevice.zip -a D0:5F:98:41:EF:CE -p COM6


and the output is:
[------------------------------------] 0%
Traceback (most recent call last):
File "nordicsemi\__main__.py", line 1555, in <module>
File "click\core.py", line 1137, in __call__
File "click\core.py", line 1062, in main
File "click\core.py", line 1668, in invoke
File "click\core.py", line 1668, in invoke
File "click\core.py", line 1404, in invoke
File "click\core.py", line 763, in invoke
File "nordicsemi\__main__.py", line 1215, in ble
File "nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_ble.py", line 475, in open
File "nordicsemi\dfu\dfu_transport_ble.py", line 162, in connect
File "nordicsemi\dfu\dfu_transport_ble.py", line 224, in jump_from_buttonless_mode_to_bootloader
File "nordicsemi\dfu\dfu_transport_ble.py", line 264, in verify_stable_connection
Exception: Connection Failure - Device not found!
[18804] Failed to execute script '__main__' due to unhandled exception!
Parents
  • Thanks, Edvin ;).

    I was afraid I needed a physical connection. So, for being sure, the output:

    (...)
    Exception: Connection Failure - Device not found!
    [18804] Failed to execute script '__main__' due to unhandled exception!

    matchs with the situation where the target doesn't have a bootloader?

    And secondly, even if the compile output says:
     

    (...)
    I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/ble_dfu -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/dfu -
    (...)


    It doesn't guarantee there is a bootloader flashed in the device with SEGGER?

    Have a great day.

  • JKP said:
    I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/ble_dfu -I../../nordic/nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/dfu

    I don't know why this is printed in your application's build log. Those are indeed files used by the bootloader. 

    The thing about bootloaders is that if you don't know how they work, then they are very difficult to use. That means that if someone else flashed a customized bootloader, it is very difficult to say what that bootloader expects. And perhaps they are using a signature that you don't have the key to utilize. 

    Normally, the way that our nRF5 SDK bootloader works is that the bootloader is flashed as a separate "application" a different place in flash. It is not part of the normal running application. This is because while the bootloader is swapping the application images, it needs to delete the application, so if the bootloader was part of the application, it would have to delete itself. 

    So you shouldn't try to include the bootloader in your application. They should be built and flashed separately, and when your bootloader is present, you can generate application images signed with the key pair that you used to build your bootloader, and upload them via BLE. 

    In case you are not familiar, this is a great guide for getting started with the bootloader in the nRF5 SDK:

     Getting started with Nordic's Secure DFU bootloader, a step by step guide 

    So do you have physical access to the device? If not, what was it programmed with in the first place? If it is a 3rd party manufacturer, they may have pre-flashed a bootloader, but for that you need to ask them.

    Best regards,

    Edvin

  • Thanks Edvin for your time and clarity.

    About your questions: the devices were programmed in the first place (in a wired way) using Segger with a nRF52840-DK as a J-link bridge to the device's SWD port. Actually I know the app loaded were just the app (and it didn't include a bootloader inside the app), My assumption at the first moment was that maybe Segger (because a linking configuration setup) loaded a softdevices before the application. AND maybe it loaded a standard bootloader (signed or not). My thought was If it exists a standard bootloader loaded unwittingly by Segger, maybe in the forum were standard ways to deal with it.

    I replicated the flashing process described above, and noticed that there IS a softdevice step, and then the application downloading (I striked the app name for security reasons)

    If I'm understanding properly no bootloader is loaded in the device.

    Then, I got access to one of the devices in the past days, using the command

    nrfjprog --readcode ses_flashed_unit.hex

    got this distribution, confirming there is no bootloader

    If I'm getting this right. and there is no bootloader in the devices, Is still a chance (even if tricky, but without physical access of course) to update application or bootloader over the air? buttonless DFU method as instance? (this units still shows this button when I connect to them with the nRF connect software).

    Thanks so much for your support

  • JKP said:
    Is still a chance (even if tricky, but without physical access of course) to update application or bootloader over the air?

    No. There is absolutely no way to update the firmware without a bootloader. 

    JKP said:
    buttonless DFU method as instance

    That is not a bootloader. That is a bluetooth service indicating that the device has a bootloader, and is used as a method of putting the device in DFU mode. It does not work without a bootloader. 

    I understand that you want to update the device without physical access, but it is not possible. Then you need to physically flash a bootloader first, and a way to enter the bootloader in DFU mode (ble_app_buttonless_dfu). 

    BR,
    Edvin

Reply
  • JKP said:
    Is still a chance (even if tricky, but without physical access of course) to update application or bootloader over the air?

    No. There is absolutely no way to update the firmware without a bootloader. 

    JKP said:
    buttonless DFU method as instance

    That is not a bootloader. That is a bluetooth service indicating that the device has a bootloader, and is used as a method of putting the device in DFU mode. It does not work without a bootloader. 

    I understand that you want to update the device without physical access, but it is not possible. Then you need to physically flash a bootloader first, and a way to enter the bootloader in DFU mode (ble_app_buttonless_dfu). 

    BR,
    Edvin

Children
No Data
Related