Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nRF connect crashes when device reports 0 bytes for DFU partition #434

Open
plaes opened this issue Feb 7, 2024 · 2 comments
Open

nRF connect crashes when device reports 0 bytes for DFU partition #434

plaes opened this issue Feb 7, 2024 · 2 comments
Labels

Comments

@plaes
Copy link

plaes commented Feb 7, 2024

When firmware accidentally reports 0 bytes available for DFU partition, then nRF connect seems to be simply crashing.

This happens with nRF connect 4.28 and (2.26 as well).

I'm developing a custom Rust-based firmware which is using DFU over BLE.
When testing with nRF connect, and attempting to push out application.zip, it crashed after the download and validation for the .dat file was complete and nRF-Connect requested to start pushing the actual firmware payload.

Log file from firmware side starts just after *.dat file has been uploaded and its CRC is going to be calculated:

19.497955: TRACE DFU REQUEST Crc
19.497985: TRACE DFU RESPONSE DfuResponse { request: Crc, result: Success, body: Some(Crc { offset: 79, crc: 611744236 }) }
19.632843: TRACE ble evt 87
19.632934: TRACE ble evt 80
19.632965: TRACE gatts write handle=16 data=[4]
19.633026: TRACE DFU REQUEST Execute
19.633087: TRACE DFU RESPONSE DfuResponse { request: Execute, result: Success, body: None }
19.767852: TRACE ble evt 87
19.767913: TRACE ble evt 80
19.767974: TRACE gatts write handle=16 data=[2, 10, 0]
19.768035: TRACE DFU REQUEST SetReceiptNotification { target: 10 }
19.768096: TRACE DFU RESPONSE DfuResponse { request: SetReceiptNotification { target: 10 }, result: Success, body: None }
19.902832: TRACE ble evt 87
19.902893: TRACE ble evt 80
19.902923: TRACE gatts write handle=16 data=[6, 2]
19.903015: TRACE DFU REQUEST Select { obj_type: Data }
19.903106: TRACE DFU RESPONSE DfuResponse { request: Select { obj_type: Data }, result: Success, body: Some(Select { offset: 0, crc: 0, max_size: 0 }) }
18.723419: TRACE ble evt 87
19.803649: TRACE ble evt 17
19.803680: TRACE on_disconnected conn_handle=3
19.803741: TRACE conn 0: disconnected
19.803771: INFO  GATT server disconnected: DisconnectedError

And at this point, nRF connect seems to be crashing due unexpected response where max_size = 0.

@philips77 philips77 transferred this issue from NordicSemiconductor/Android-nRF-Connect Feb 7, 2024
@philips77
Copy link
Member

Hi, thank you for the bug report.
This issue seems to be more related to the DFU library, rather than nRF Connect, so I moved it here.

The crash may come from this line:

final int chunkCount = (mImageSizeInBytes + info.maxSize - 1) / info.maxSize;

We're in XXI century and humanity still can't divide by 0.

Fixing this issue is a bit difficult, as there's no clear solution what to do in such case. Should it select the object again, hoping for non-zero value, or abort? Of course, crashing is the worst option.

Anyway, I hope you can fix it on your side, as I'm quite busy with other tasks and this one will have to wait.

@philips77 philips77 added the bug label Feb 7, 2024
@plaes
Copy link
Author

plaes commented Feb 7, 2024

Hi, thank you for the bug report. This issue seems to be more related to the DFU library, rather than nRF Connect, so I moved it here.

The crash may come from this line:

final int chunkCount = (mImageSizeInBytes + info.maxSize - 1) / info.maxSize;

We're in XXI century and humanity still can't divide by 0.

Fixing this issue is a bit difficult, as there's no clear solution what to do in such case. Should it select the object again, hoping for non-zero value, or abort? Of course, crashing is the worst option.

Ideally DFU process is aborted and relevant error is bubbled up to the UI as device seems to be unable to accept the firmware.

Anyway, I hope you can fix it on your side, as I'm quite busy with other tasks and this one will have to wait.

Yeah, I already figured this out and "worked it around" from firmware side where I had a typo in the DFU partition length calculation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants