Unknown response received #436

sedwo · 2021-06-23T14:44:10Z

Xcode 12.5, iOS 14.6, iPhone XS

I'm struggling to understand the issue here when I try to update the firmware using your iOS example code.

Logs

Central Manager is now powered on
Start discovery
State changed to: Connecting
D: [Callback] Central Manager did update state to: Powered ON
V: Connecting to <device>...
D: centralManager.connect(peripheral, options: nil)
D: [Callback] Central Manager did connect peripheral
I: Connected to <device>
V: Discovering services...
D: peripheral.discoverServices(nil)
I: Services discovered
V: Starting Secure DFU...
I: Connected to <device>
I: Services discovered
V: Secure DFU Service found
V: Discovering characteristics in DFU Service...
D: peripheral.discoverCharacteristics(nil, for: FE59)
I: DFU characteristics discovered
V: MTU set to 247
State changed to: Starting
V: Enabling notifications for 8EC90001-F315-4F60-9FB8-838830DAEA50...
D: peripheral.setNotifyValue(true, for: 8EC90001-F315-4F60-9FB8-838830DAEA50)
V: Notifications enabled for 8EC90001-F315-4F60-9FB8-838830DAEA50
A: Secure DFU Control Point notifications enabled
V: Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
D: peripheral.writeValue(0x0601, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse)
I: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600601800000000000000000000000003cb7423f
E: Unknown response received: 0x600601800000000000000000000000003cb7423f
V: Disconnecting...
D: centralManager.cancelPeripheralConnection(peripheral)
D: [Callback] Central Manager did disconnect peripheral
I: Disconnected
Error 307: Unsupported response received: 0x600601800000000000000000000000003cb7423f
2021-06-23 01:53:33.508852-0400 DFU Example[8659:1734378] [CoreBluetooth] XPC connection invalid

Can you perhaps shine some light on this Unknown response received: 0x600601800000000000000000000000003cb7423f error?

The text was updated successfully, but these errors were encountered:

philips77 · 2021-06-23T15:09:38Z

You request (0x):

D: peripheral.writeValue(0x0601, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse)

06 - Request Op Code: Select
01 - Command Object

Spec says (https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_dfu_transport.html#lib_dfu_transport_op_select):

Select request
The Select request triggers the last transferred object of the specified object type to be selected, thus to be made the currently active object. It also requests information about the object (the maximum size, the current offset, and the current CRC). If there is no valid object of that type, the object type is still selected. In this case, the returned CRC and offset are zero.

The response you got is (0x):

I: Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600601800000000000000000000000003cb7423f

60 - Response Op Code
06 - For Request Op Code: Select Object
01 - Status (Success)
// Here you should get 3 times UInt32 (3*4 bytes), instead you get:
80000000 - Max Size??? Usually it should be 0x00010000 = 256 bytes
00000000 - Offset: 0 bytes
0000000000 - What is that?
3cb7423f - This looks like CRC 32.

The Max Size and "What is that?" above are incorrect.

sedwo · 2021-06-23T15:24:26Z

// Here you should get 3 times UInt32 (3*4 bytes), instead you get:
80000000 - Max Size??? Usually it should be 0x00010000 = 256 bytes
00000000 - Offset: 0 bytes
0000000000 - What is that?

Good question. ¯\(ツ)/¯

My manifest looks like this:

{
    "manifest": {
        "application": {
            "bin_file": "deviceV3.bin",
            "dat_file": "firmware.dat",
            "init_packet_data": {
                "application_version": 205521022,
                "device_revision": 2,
                "device_type": 48299,
                "firmware_crc16": 33905,
                "firmware_size": 1300464
            }
        }
    }
}

philips77 · 2021-06-23T15:28:28Z

Your file is for legacy DFU, but the device is using Secure DFU. Also, seems like you have endianness wrong? Really the brain numbers are so big? It may also be cache. Try restarting Bluetooth on the iPhone any try again.

sedwo · 2021-06-23T15:47:59Z

I thought perhaps that it might be an invalid firmware zip package, but regardless of what firmware zip I choose to test with from the demo samples, the same error response arrives. Cycling the Bluetooth on the iPhone didn't change anything. The nRF Connect iOS app doesn't seem to expose any more information either.

Is this perhaps a hardware config/setup detail?

philips77 · 2021-06-24T08:00:33Z

Did you try DFU on Android? Using nRF Connect for Android. Could you paste the logs from the app?

sedwo · 2021-06-24T13:10:51Z

I did not, and can't currently, as this is primarily an iOS app and don't have access to an Android device.

philips77 · 2021-06-24T13:33:20Z

Then how about logs from nRF Connect for iOS?

philips77 · 2021-06-24T13:34:54Z

The issue seems to be on your device side. Is it the standard bootloader, or has it been modified? Why the notification it sends is in wrong format and the values look incorrect? E.g., with offset = 0, the CRC should also be 0.

sedwo · 2021-06-24T21:55:52Z

Here are two log files from the nRF Connect app. The Android seems to succeed. While the iOS fails with that error. It seems as if there is a discrepancy between how each mobile device handles the communication. For example, I don't see the Android app sending a 0x0601.

Android Log 2021-06-24 .txt
iOS Log D0AFC822C01B-1.txt

philips77 · 2021-06-25T08:09:42Z

Ok, I can see the difference between Android and iOS. Android actually also sends 0x06-01, but the log gets corrupted (on Android there's a shared buffer for sending and receiving data, so in here:

V	21:35:11.726	[DFU] Writing to characteristic 8ec90001-f315-4f60-9fb8-838830daea50
D	21:35:11.726	[DFU] gatt.writeCharacteristic(8ec90001-f315-4f60-9fb8-838830daea50)
I	21:35:11.767	[DFU] Notification received from 8ec90001-f315-4f60-9fb8-838830daea50, value (0x): 60-06-01-80-00-00-00-00-00-00-00-00-00-00-00-00-5C-B7-42-3F
I	21:35:11.775	[DFU] Data written to 8ec90001-f315-4f60-9fb8-838830daea50, value (0x): 60-06-01-80-00-00-00-00-00-00-00-00-00-00-00-00-5C-B7-42-3F
A	21:35:11.779	[DFU] Command object info received (Max size = 128, Offset = 0, CRC = 00000000)

The "data written" actually displays what has been received, as notification comes even before the write confirmation callback. It should be:

V	21:35:11.726	[DFU] Writing to characteristic 8ec90001-f315-4f60-9fb8-838830daea50
D	21:35:11.726	[DFU] gatt.writeCharacteristic(8ec90001-f315-4f60-9fb8-838830daea50)
I	21:35:11.767	[DFU] Notification received from 8ec90001-f315-4f60-9fb8-838830daea50, value (0x): 60-06-01-80-00-00-00-00-00-00-00-00-00-00-00-00-5C-B7-42-3F
I	21:35:11.775	[DFU] Data written to 8ec90001-f315-4f60-9fb8-838830daea50, value (0x): 06-01
A	21:35:11.779	[DFU] Command object info received (Max size = 128, Offset = 0, CRC = 00000000)

The difference between Android and iOS implementation of DFU library is that Android just reads (0x):

60 - Response Op Code
06 - Request Op Code (Select)
01 - Status (Success)
80-00-00-00 - Max Object Length in Little Endiann = 128 bytes (0x00-00-00-80)
00-00-00-00 - Offset = 0
00-00-00-00 - CRC = 0
00-5C-B7-42-3F - the rest is being ignored

iOS implementation, on the other hand, validates the response and rejects if it's too long, returning an error.
I'm about to release a new version of DFU Library for iOS today, so I can look at it.

However, this doesn't change the situation, that the root cause of this failure is in your DFU bootloader implementation. It should send 3+4+4+4 bytes, not more, in this notification.

philips77 · 2021-06-25T11:50:04Z

Your experience should improve with version 4.10.4, where I don't check the notifications that strictly. This should be released in nRF Connect for iOS in some time.

sedwo · 2021-06-25T16:33:19Z

Good work @philips77 , your recent update to the DFU library (v4.10.4) for iOS worked to resolve the error state I was experiencing and the device updated successfully with my new firmware sample. The hardware dev will also be fixing the DFU bootloader implementation as per your feedback.

Thanks again.

sedwo added the question label Jun 23, 2021

This was referenced Jun 25, 2021

Accepting garbage in notifications following valid data #440

Merged

Version 4.10.4 #441

Merged

philips77 closed this as completed Jun 25, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unknown response received #436

Unknown response received #436

sedwo commented Jun 23, 2021

philips77 commented Jun 23, 2021

sedwo commented Jun 23, 2021 •

edited

Loading

philips77 commented Jun 23, 2021

sedwo commented Jun 23, 2021

philips77 commented Jun 24, 2021 •

edited

Loading

sedwo commented Jun 24, 2021

philips77 commented Jun 24, 2021

philips77 commented Jun 24, 2021

sedwo commented Jun 24, 2021

philips77 commented Jun 25, 2021

philips77 commented Jun 25, 2021

sedwo commented Jun 25, 2021

Unknown response received #436

Unknown response received #436

Comments

sedwo commented Jun 23, 2021

philips77 commented Jun 23, 2021

sedwo commented Jun 23, 2021 • edited Loading

philips77 commented Jun 23, 2021

sedwo commented Jun 23, 2021

philips77 commented Jun 24, 2021 • edited Loading

sedwo commented Jun 24, 2021

philips77 commented Jun 24, 2021

philips77 commented Jun 24, 2021

sedwo commented Jun 24, 2021

philips77 commented Jun 25, 2021

philips77 commented Jun 25, 2021

sedwo commented Jun 25, 2021

sedwo commented Jun 23, 2021 •

edited

Loading

philips77 commented Jun 24, 2021 •

edited

Loading