Thread+BLE,DFU through ble

[NOA-BEN]

Hi, nordic engineer:

          Our project has a function, that is, BLE+Thread coexists. We hope that the mobile phone can upgrade the device through BLE. Can this idea be realized?

          I tried to burn softdecvice+bootloader, then use the mobile phone to give the device DFU. After the upgrade is completed, let the device power off and restart, the device does not jump to the application, but enters DFU mode again.

          The SDK version I currently use is nRF5_SDK_for_Thread_and_Zigbee_v3.1.0_c7c4730. I see some conflicts between the BLE DFU partition and the openthread data store. Can you tell me how to change it

[Vidar Berg]

Hi,

I don't see any problems with using the BLE bootloader on the same device as a BLE+Thread app. I would suggest that you try to debug the bootloader after DFU to find out why it falls back to DFU mode instead of booting the app.  First step can be to place breakpoints in nrf_bootloader.c::dfu_enter_check() and see if it returns true. 

The memory layout should be ok, but make sure that NRF_DFU_APP_DATA_AREA_SIZE in the bootloader project corresponds with the number of flash pages used by your application (OT Data + FDS pages if you use FDS in your app). 

[NOA-BEN]

Hi Vidar:

           I compiled  this project and generated a application hex file . File Directory is:examples\multiprotocol\ble_thread\ble_thread_dyn_mtd_coap_cli.

          And i  program softdevice and bootloader hex to board.

        From the printed data, DFU is complete, but it cannot jump to the application.ble_thread_dyn_mtd_coap_cli_pca10056_s140.hex8103.s140_nrf52_6.1.1_softdevice.hexsyc_app3.zip

          

 0> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FE000, len=1 pages), queue usage: 3
 0> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FE000, src=0x2000A698, len=896 bytes), queue usage: 4
 0> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
 0> <debug> app: timer_stop (0x20005944)
 0> <debug> app: timer_activate (0x20005944)
 0> <debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 4
 0> <debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 3
 0> <debug> nrf_dfu_flash: Flash erase success: addr=0x000FE000, pending 2
 0> <debug> nrf_dfu_flash: Flash write success: addr=0x000FE000, pending 1
 0> <debug> nrf_dfu_req_handler: All flash operations have completed. DFU completed.
 0> <debug> app: Shutting down transports (found: 1)
 0> <debug> nrf_dfu_ble: Shutting down BLE transport.
 0> <debug> nrf_dfu_ble: Disconnecting.
 0> <debug> nrf_dfu_ble: BLE transport shut down.
 0> <debug> app: Resetting bootloader.
 0> <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
 0> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
 0> <info> app: Inside main
 0> <debug> app: In nrf_bootloader_init
 0> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
 0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
 0> <debug> nrf_dfu_settings: Using settings page.
 0> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
 0> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
 0> <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
 0> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
 0> <debug> app: Enter nrf_bootloader_fw_activate
 0> <debug> app: Valid App
 0> <debug> app: Enter nrf_dfu_app_continue
 0> <debug> app: No copy needed
 0> <debug> app: Setting app as valid
 0> <debug> nrf_dfu_settings: Writing settings...
 0> <debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
 0> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 0
 0> <debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 0
 0> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, src=0x2000A318, len=896 bytes), queue usage: 1
 0> <debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0
 0> <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
 0> <debug> nrf_dfu_settings: Writing settings...
 0> <debug> nrf_dfu_settings: Erasing old settings at: 0x000FE000
 0> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FE000, len=1 pages), queue usage: 1
 0> <debug> nrf_dfu_flash: Flash erase success: addr=0x000FE000, pending 0
 0> <debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FE000, src=0x2000A698, len=896 bytes), queue usage: 1
 0> <debug> nrf_dfu_flash: Flash write success: addr=0x000FE000, pending 0
 0> <debug> app: Resetting bootloader.
 0> <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
 0> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
 0> <info> app: Inside main
 0> <debug> app: In nrf_bootloader_init
 0> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
 0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
 0> <debug> nrf_dfu_settings: Using settings page.
 0> <debug> nrf_dfu_set

[Vidar Berg]

Hi,

I would like to test this here, but it looks like the bootloader hex is missing?

[NOA-BEN]

Hi, Vidar:

        sorry, I forget to add bootloader. I will add now.secure_bootloader_ble_s140_pca10056_debug.hex

[Vidar Berg]

Hi,

The DFU part seems to be working, but there is a hardfault in the main app after it's complete. Have you tried to debug the application after it's uploaded? The first step could be to check if it even reaches main().

Edit: I think it has to be to ot_flash_data section, it seems to be placed at a fixed address, unlike the FDS pages that are placed dynamically depending on the bootloader start address. So I suspect the app is 'hardfaulting' when it tries to access the page because it's overlapping with the bootlaoder. Can you try to move it to address 0xf0000?

  <MemorySegment name="ot_flash_data" start="0xf0000" size="0x4000">
    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".ot_flash_data" address_symbol="__start_ot_flash_data" end_symbol="__stop_ot_flash_data" start = "0xf0000" size="0x4000" />
  </MemorySegment>
</Root>

[NOA-BEN]

Hi, Vidar:

        Yes, I also feel that the OT flash and the partition boot table overlap. And after DFU is completed, the bootloader program is stuck in this place. settings_backup_valid always false.

      And I found that the address space used by the boot sector program is 0x000-0x100000. And I tried to change the start address of the OT flash to 0xf0000. Problem still

[Vidar Berg]

NOA-BEN said:

And after DFU is completed, the bootloader program is stuck in this place. settings_backup_valid always false.

That didn't happen when I tried the hex files you uploaded earlier. Is it stuck, or is it going in a bootloop? If stuck, try to call "nrfjprog --readregs" and post the result here. 

[NOA-BEN]

Hi Vidar:

           I don't know what happened, the print serial port doesn't print the data anymore。

            

nrfjprog --readregs
R0:   0x00000068
R1:   0x0002503C
R2:   0x00026000
R3:   0x00026363
R4:   0x200001B4
R5:   0x00000001
R6:   0x000C5C10
R7:   0x00000000
R8:   0x2003FE98
R9:   0x00000000
R10:  0x00000000
R11:  0x00000000
R12:  0xFFFFFFFF
SP:   0x2003FE08
LR:   0xFFFFFFF1
PC:   0x00026362
xPSR: 0x21000003
MSP:  0x2003FE08
PSP:  0x00000000

[Vidar Berg]

Hi,

Yes, that's the same as I got. The program is stuck in the Application's hardfault handler at address 0x26362. Probably before the app has had time to start logging. Are you able to debug the app after DFU?