REQUEST AN IOS VERSION DFU UPGRADE PROCESS

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Tue, 05 Nov 2024 09:24:36 GMT

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

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Mon, 04 Nov 2024 12:53:44 GMT

[quote userid="135216" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508939"]callback determines the update status of the MTU:[/quote]

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?

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Mon, 04 Nov 2024 12:20:03 GMT

Hi Vidar，

1.I use “nrf_ble_gatt_att_mtu_periph_set”to set the MTU size of the GATT server.The GATT event callback determines the update status of the MTU:

void gatt_evt_handler(nrf_ble_gatt_t * p_gatt,nrf_ble_gatt_evt_t const * p_evt)
{
if ((m_conn_handle == p_evt->conn_handle) && (p_evt->evt_id == NRF_BLE_GATT_EVT_ATT_MTU_UPDATED))
{
NRF_LOG_INFO("Data len is set to 0x%X(%d)",
p_evt->params.att_mtu_effective-OPCODE_LENGTH-HANDLE_LENGTH,
p_evt->params.att_mtu_effective-OPCODE_LENGTH-HANDLE_LENGTH
);
}
}

2.I only tested with my project,since routine example don't work on my board

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Mon, 04 Nov 2024 11:50:11 GMT

Hi Anny,

[quote user="ANNY-TAO"]I just made a judgment to determine the change in the MTU value.[/quote]

Can you post some code snippets showing how you are handling MTU and Data length extension?

[quote user="ANNY-TAO"]The original routine works fine on one of the boards used, and the connection works fine. But the program doesn't work on my PCB board[/quote]

Were you able to run the original ble_app_uart example on your custom board, or have you only tested with your project?

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Mon, 04 Nov 2024 11:24:32 GMT

Hi Vidar，

[quote userid="4240" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508929"]And you have not implemented any handling of these events in your application?[/quote]

I just made a judgment to determine the change in the MTU value.

[quote userid="4240" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508929"]Do you see the same issue if you attempt to connect with the original ble_app_uart example?[/quote]

The original routine works fine on one of the boards used, and the connection works fine. But the program doesn't work on my PCB board

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Mon, 04 Nov 2024 11:12:49 GMT

Hello Anny,

And you have not implemented any handling of these events in your application? Do you see the same issue if you attempt to connect with the original ble_app_uart example?

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Mon, 04 Nov 2024 11:11:10 GMT

Hello Vidar，

[quote userid="4240" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508790"]Does your application use the GATT module to handle data length update requests? [/quote]

Yes, I added the relevant setting functions according to the example-"ble_app_uart",

err_code = nrf_ble_gatt_init(&m_gatt,gatt_evt_handler);
APP_ERROR_CHECK(err_code);

err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt,NRF_SDH_BLE_GATT_MAX_MTU_SIZE);
APP_ERROR_CHECK(err_code);

however,it did not work.Somehow, the program went into NRF_FAULT_ID_SD_ASSERT state after receiving a 0X22 error reply.Do I need to do anything extra in the handler？

I’m looking forward for your reply!

Anny

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Fri, 01 Nov 2024 11:00:03 GMT

Hello Anny,

[quote userid="135216" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508785"]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?[/quote]

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

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Fri, 01 Nov 2024 10:32:18 GMT

Hello Vidar,

[quote userid="4240" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508758"]Do you know what caused the jump address to become invalid?[/quote]

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.

[quote userid="4240" url="~/f/nordic-q-a/115981/request-an-ios-version-dfu-upgrade-process/508758"]Could you please provide more information about how the connection is failing to establish?[/quote]

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?

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Fri, 01 Nov 2024 08:03:17 GMT

Hello Anny,

[quote user="ANNY-TAO"]As you said it's an issue with the initial jump address, I already found out yesterday.[/quote]

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

[quote user="ANNY-TAO"]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?[/quote]

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

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

ANNY-TAO — Fri, 01 Nov 2024 01:16:39 GMT

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

RE: REQUEST AN IOS VERSION DFU UPGRADE PROCESS

Vidar Berg — Thu, 31 Oct 2024 12:43:44 GMT

Hello,

[quote user=""]00> <debug> nrf_dfu_validation: CRC check of app failed. Return 1[/quote]

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