REQUEST AN IOS VERSION DFU UPGRADE PROCESS

[ANNY-TAO]

DFU is now implemented on ipads and iphones, as well as on Android phones, and the app platform is nRF Connect. The problem is that the firmware upgrade can be achieved normally with an Android phone; The ipad can connect and read data, but it can't use the DFU function; iPhones can't connect to Bluetooth; Observe the log information in the process of iPad DFU, and observe <debug> nrf_dfu_validation: CRC check of app failed. What is the reason for such a sentence as Return 1? And the IPAD can establish a connection with the firmware bluetooth, but the iphone15 can't establish a connection, what could be the problem?

The version of SDK is 17.0.2；
The following is the information for the wrong printing:

1. 00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
   00>
   00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
   00>
   00> <info> app: Inside main
   00>
   00> <debug> app: In nrf_bootloader_init
   00>
   00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
   00>
   00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
   00>
   00> <debug> nrf_dfu_settings: Using settings page.
   00>
   00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <debug> app: Enter nrf_bootloader_fw_activate
   00>
   00> <info> app: No firmware to activate.
   00>
   00> <debug> nrf_dfu_validation: CRC check of app failed. Return 1
   00>
   00> <debug> app: App is valid
   00>
   00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
   00>
   00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
   00>
   00> <info> app: Inside main
   00>
   00> <debug> app: In nrf_bootloader_init
   00>
   00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
   00>
   00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
   00>
   00> <debug> nrf_dfu_settings: Using settings page.
   00>
   00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <debug> app: Enter nrf_bootloader_fw_activate
   00>
   00> <info> app: No firmware to activate.
   00>
   00> <debug> app: App is valid
   00>
   00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
   00>
   00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
   00>
   00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
   00>
   00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
   00>

[Vidar Berg]

ANNY-TAO said:

callback determines the update status of the MTU:

Thanks, this will not interfere with the MTU exchange, so it must be something else that is handled different in your project, but it's difficult to say what it is without having seen the project. Have you changed the ble_evt_handler() compared to the ble_app_uart example?

[ANNY-TAO]

Hi Vidar，

As you predicted, I didn't make an update to the PHY request for the two connected devices in the BLE Handler!The final problem arises at the application layer, and I wasn't aware of the version issue with Bluetooth before.

Thank you so much for your reply！

Anny