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]

Hello,

00> <debug> nrf_dfu_validation: CRC check of app failed. Return 1

The debug message indicates that the computed checksum of the application does not match the expected checksum stored in the bootloader settings page. However, the bootloader is allowed to boot the image anyway, as you are using the debug variant of the bootloader, which sets the NRF_DFU_DEBUG flag. This suggests that the application image was altered after the DFU was completed. It's strange that this only happens with iOS/ipadOS and not Android. 

Can you read out the flash after completing DFU with Android and iOS to compare the differences? You can do this with nrfjprog.

$ nrfjprog --memrd <application start address> --n <size of application image in bytes> > app_image.txt

Best regards,

Vidar

[ANNY-TAO]

Hello Vidar,thanks a lot for your reply.

As you said it's an issue with the initial jump address, I already found out yesterday.

One of the more strange problems is found at the moment, because the previous version of the iPad version 16.6.1 was used to implement the Bluetooth connection, but when using the iPhone with the iOS version 18, the Bluetooth connection could not be realized. Will the Bluetooth connection of the NRF52832 be related to the system version? Do I need to set any relevant parameters?

Best regards，

Anny

[Vidar Berg]

Hello Anny,

ANNY-TAO said:

As you said it's an issue with the initial jump address, I already found out yesterday.

Do you know what caused the jump address to become invalid? The DFU client (iPad or iPhone) does not control the boot sequence.

ANNY-TAO said:

One of the more strange problems is found at the moment, because the previous version of the iPad version 16.6.1 was used to implement the Bluetooth connection, but when using the iPhone with the iOS version 18, the Bluetooth connection could not be realized. Will the Bluetooth connection of the NRF52832 be related to the system version? Do I need to set any relevant parameters?

Could you please provide more information about how the connection is failing to establish? I haven't noticed any Bluetooth related changes after updating my phone to iOS 18.0.1. I've also performed DFU with the nRF5 SDK without issues. 

Best regards,

Vidar

[ANNY-TAO]

Hello Vidar,

Vidar Berg said:

Do you know what caused the jump address to become invalid?

Unfortunately, I'm not very clear about this. However, after I modify the definition symbol __ICFEDIT_region_RAM_start__ address in the icf file, the DFU function can be implemented normally. I haven't tried more situations yet.

Vidar Berg said:

Could you please provide more information about how the connection is failing to establish?

If you connect with an iPhone phone, the following reply will appear：

00> Connected. conn_handle:0x0000
00> Connected. conn_Param:24,24,0,72
00> <info> app: conn_Param Updata : 24,24,0,72
00> <info> app: Disconnected. conn_handle: 0x0, reason: 0x22

Based on the return value 0x22, I modified the value of the MTU, with a minimum of 27 and a maximum of 251，It didn't work out. And when the phone is connected, it will always be in the connecting state。Do I need to switch to any other settings?

[Vidar Berg]

Hello Anny,

ANNY-TAO said:

Based on the return value 0x22, I modified the value of the MTU, with a minimum of 27 and a maximum of 251，It didn't work out. And when the phone is connected, it will always be in the connecting state。Do I need to switch to any other settings?

Does your application use the GATT module to handle data length update requests? The disconnect reason is BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT (0x22), which indicates that either the phone or app failed to respond to a link layer control procedure request.

Best regards,

Vidar