I have used sofdevice v7.1.0 and nrf51 sdk 6.1.0 the ble_app_hrs project which has support of dfu is not discovering the dfu services. i have enabled the BLE_DFU_APP_SUPPORT flag , then also facing same issue.
I have used sofdevice v7.1.0 and nrf51 sdk 6.1.0 the ble_app_hrs project which has support of dfu is not discovering the dfu services. i have enabled the BLE_DFU_APP_SUPPORT flag , then also facing same issue.
i have attached the 3 files of mcp screen shot.
@komal: Let me sum up the issue you are having, please correct me if I am wrong:
This is normal behaviour. MCP v3.7 and SDK v6.1 doesn't support seamless DFU update from application to jump to bootloader and do update automatically. What you need to do is to click back, then do Start Discovery to see if the DFU is advertising, if it is advertising you can connect and do DFU. So 2 more step needed, click back and click start discovery to find the DFU bootloader advertising.
On newer SDK (where you have to update the python code in ble_dfu_send_hex\dfu into C:\Program Files (x86)\Nordic Semiconductor\Master Control Panel\3.7.1.8567\lib\dfu) such as SDK v7.1 the Master Control Panel can do update seamlessly from the dfu buttonless application.
no. this is not the issue i am facing. When I write 1 to the DFU Control Point, link loss takes place. Then i click back, the do start discovery and the dfutarg gets advertised. Then i do service discovery, then services get discovered and i get link loss. that means 2nd tme i cant update my firmware.
@komal: It's pretty strange issue. Because you can update the ble_app_hrs_dfu the first time without problem, why didn't it work the second time. Could you provide the Master Control panel log. You can get the log by selectin File -> Log File.
Do you have the same issue if you enter bootloader by holding the BOOT button instead of entering if by writing to the DFU control point ?