Buttonless DFU connect timeout issue on custom board

[gte938x]

Hi,

I followed the DFU to SDK example post on https://www.u-blox.com/en/docs/UBX-19050198 to add Buttonless DFU to an application (I modified \ble_peripheral\ble_app_hrs). The details of firmware updates and HEX file generation are in section 5. Then All the testing in section 6 is successful when I used nRF52832DK to test uploading new version hrs application though buttonless DFU (using nRFconnect and another DK). The SDK I used is 17.0.2.

Then I repeated everything on my custom nRF52832 board, with the same changes applied to my custom application.

I also updated the secure bootloader under “\examples\dfu\secure_bootloader” for my custom board to generate “secure_bootloader_ble_s132_custom.hex”. The main changes are (1) Replace board.c, board.h (remove all the buttons and unused LEDs related code, since my board has no button and only two LEDs), add custom_board.h. (2) Changed softdevice clock setting macros in sdk_config.h, since I do not use external 32MHz crystal.  The bootloader was tested successfully with my customer board. I can see “DfuTarg” as the advertising name. OTA firmware upload is successful with my custom application .zip file (generated with command “nrfutil pkg generate --application custom.hex --application-version-string "2.0.0" --hw-version 52 --sd-req 0x101 --key-file private.key app_v2.zip”)

However, after I generated the combined .hex following steps in section 5, (merge bl_setting.hex, such successfully tested bootloader, softdevice image, and my updated application), downloaded such combined .hex file to my custom board. Recycle power and connect my custom board and application through nRF connect, click DFU button and start OTA uploading, the DFU always gives a message says “dfu failed with error: connect time out” after about 10 seconds waiting.

The downloaded .hex file (bl_set_s132_app.hex) is generated as below

• nrfutil settings generate --family NRF52 --application custom.hex --application-version-string "1.2.3" --bootloader-version 0 --bl-settings-version 2 bl_setting.hex
• mergehex --merge bl_setting.hex secure_bootloader_ble_s132_custom.hex s132_nrf52_7.2.0_softdevice.hex --output bl_set_s132.hex
• mergehex --merge bl_set_s132.hex custom.hex --output bl_set_s132_app.hex

Then I download to custom board though

• nrfjprog -f nrf52 –recover
• nrfjprog --program bl_set_s132_app.hex

The .zip file for uploading though buttonless DFU is generated as below.

nrfutil pkg generate --application custom.hex --application-version-string "2.0.0" --hw-version 52 --sd-req 0x101 --key-file private.key app_v2.zip

Since I did exactly the same changes and everything is working on nRF52832DK, may I know what is the possible cause of such “connect time out” issue on my customer board? For example, does bootloader use a timer and accidently occupied by my customer application? It could explain why modified secure_bootloader can do OTA upload successfully, but DFU button on my application has time out error. If so, how to check that?

I already tried method (add “do while” to  sd_ble_gatts_hvx) following the link https://devzone.nordicsemi.com/f/nordic-q-a/38655/buttonless-dfu-sdk-14-2-dfu-failed-with-error

But it still does not working for me.

Appreciate all the helps and suggestions.

[gte938x]

Here is another segment from my original posting story about button

"Replace board.c, board.h (remove all the buttons and unused LEDs related code, since my board has no button and only two LEDs), add custom_board.h.

[gte938x]

Replay the code, it looks the time out error 'DFU Failed with error. Connect time out" message is about 20 seconds after the last post message "Attribute value changed, handle:0x18, value (0x): 20-01-01". Please ignore all the 10 seconds information. It was an estimation without accurate measurement.

[gte938x]

OK, I was able to find some differences between the hrs example and my application (both were modified the same way based on section 5 of the APP note to add buttonless DFU service). 

I set a breakpoint in "nrf_pwr_mgmt.c" at 

if ((m_pwr_mgmt_evt == NRF_PWR_MGMT_EVT_PREPARE_RESET)
|| (m_pwr_mgmt_evt == NRF_PWR_MGMT_EVT_PREPARE_DFU))
{
NVIC_SystemReset();
}

In my application, after I connect through nRF connect and click the dfu button, and load the app_v2.zip, it runs to "NVIC_SystemReset()". Step over (presse F10 in segger) will jump to  

SCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
SCB_AIRCR_SYSRESETREQ_Msk );

in core_cm4.h

However, if I do the same thing for hrs example, and runs to "NVIC_SystemReset()". Step over will jump to some kind of assembly code.

4B01    ldr r3,
681B    ldr r3, [r3]
68DB   ldr r3, [r3, #12]
4718    bx r3

........

It looks soft reset has some issues for my application,

But the way, after time out of my application, it advertises as "DfuTarg", which is bootloader only. Then I can successfully do OTA. It is normal, as I said the bootloader alone was a success after I modified board.c, board.h, add custom_board.h and modified sdk_config.h (since my custom board has no 32.768 kHz crystal).

[Sigurd]

gte938x said:

after time out of my application

No sure what time out you are referring to here.

gte938x said:

But the way, after time out of my application, it advertises as "DfuTarg", which is bootloader only. Then I can successfully do OTA. It is normal, as I said the bootloader alone was a success after I modified board.c, board.h, add custom_board.h and modified sdk_config.h (since my custom board has no 32.768 kHz crystal).

Ok, good!

[gte938x]

I solved the issue. I set resolvable private address before executing advertising_start(), but not in the bootloader. The device would reset into the bootloader and use a completely different address (the default random static address from FICR). So the DFU master / central would not see that it is the same device. Disable setting resolvable private address solve the problem.