Stuck at "validate" step on 1.2.5, works on 1.1.0

[NeverwinterMoon]

Only on 1.2.5, works on 1.1.0:

upgradeStateDidChange requestMcuMgrParameters
McuMgrLog message: Central Manager  ready
McuMgrLog message: Connecting...
McuMgrLog message: Peripheral connected
McuMgrLog message: Discovering services...
McuMgrPeripheral peripheral [381CA91F-3E34-5C92-8057-CDA22EA02871] state: [connecting]
McuMgrPeripheral peripheral [381CA91F-3E34-5C92-8057-CDA22EA02871] state: [initializing]
McuMgrLog message: Services discovered: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
McuMgrLog message: Discovering characteristics...
McuMgrLog message: Characteristics discovered: DA2E7828-FBCE-4E01-AE9E-261174997C48
McuMgrLog message: Enabling notifications...
McuMgrLog message: Notifications enabled
McuMgrPeripheral peripheral [381CA91F-3E34-5C92-8057-CDA22EA02871] state: [connected]
McuMgrLog message: Device ready
McuMgrLog message: -> 0x0000000100000006a0
McuMgrLog message: <- 0x0100000600000006bf62726308ff
upgradeStateDidChange validate
McuMgrLog message: -> 0x0000000100010000a0
McuMgrLog message: Sending the request timed out.

[hubpav]

We face the same issue. The Android variant of the library works well though.

[Fabbi]

I get that, too. Any progress on this?

[dinesharjani]

So, question: is the app stuck in 'VALIDATING', or is there an Error as shown in the logs above? The logs show that validate starts, the validation message is sent, but no response is received, triggering an error.

Those would be two different things: 1) stuck in VALIDATING, meaning it stays like that for 1-2 minutes and beyond. 2) It Timeouts with an Error after about 1 minute or less, this is an issue wherein an Error is received from the device after sending it the VALIDATE command.

[dinesharjani]

Anyway, I'm preparing an update, 1.2.6, with the proposed fix by @RickGroenewegen

[Fabbi]

It sends the Image List command and times out afterwards (I guess like @NeverwinterMoon described (perhaps he should rename the issue)).

The fix by @RickGroenewegen doesn't help in this scenario (although it at least communicates the failure now).

dfu  -︎  Upgrade started with 1 images using 'Test And Confirm' mode
dfu  -︎  Requesting device capabilities...
default  -︎  Sending read command (Group: default, seq: 0, ID: McuMgrParameters): nil
transport  -︎  Connecting...
transport  -︎  Peripheral connected
transport  -︎  Discovering services...
transport  -︎  Services discovered: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
transport  -︎  Discovering characteristics...
transport  -︎  Characteristics discovered: DA2E7828-FBCE-4E01-AE9E-261174997C48
transport  -︎  Enabling notifications...
transport  -︎  Notifications enabled
transport  -︎  Device ready
transport  -︎  -> 0x0000000100000006a0
transport  -︎  <- 0x0100000600000006bf62726308ff
default  -︎  Response (Group: default, seq: 0, ID: 6): {"rc" : 8}
dfu  -︎  Device capabilities not supported
dfu  -︎  Sending Image List command...
image  -︎  Sending read command (Group: image, seq: 0, ID: State): nil
transport  -︎  -> 0x0000000100010000a0
transport  -︎  Sending the request timed out.
image  -︎  Request (Group: image, seq: 0) failed: Sending the request timed out.)
dfu  -︎  Sending the request timed out.

[dinesharjani]

Can you test if the issue still happens if you set the number of buffers to 'Disabled' ?

DFU will be a lot slower, but to test. I might have an inkling on the issue.

[Fabbi]

still times out with buffers set to "Disabled"

[Fabbi]

I'm digging into the code and I noticed that McuMgrBleTransportWriteState expects 259 bytes for the read image command and first receives 244 bytes from sequenceNumber 0 and another 15 bytes (so the missing 15 bytes) from sequenceNumber 116 which it discards as the sequenceNumber doesn't match.

Seems like data.readMcuMgrHeaderSequenceNumber is the culprit

Edit: I can make a PR tomorrow

[dinesharjani]

Marking as closed.