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,

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?