app_error_fault_handler / SDK V17.0.0 / SD S140 v6.1.1 / nRF52833 Custom board / id = 0x00000001 / PC=0x00014AA6 / nRFConnect for Desktop v3.4.2 / Secured Bootloader (semi-custom) / DFU OTA failed

[Harry]

Hi,

I understand I shouldn't use S140 v6.1.1 with SDK v17.0.0, but we want to try to keep using v6.1.1 as it's been well tested. Since the ATT_MTU example works with this setup, we have a high hope it will work for DFU OTA as well.

The reason for the move to SDK v17.0.0 because of the new project iteration uses nRF52833.

It is a Bootloader OTA application, taken from the Bootloader component (SDK library), with a thin layer of our wrapper.

It advertises, it connects, but then when I started the DFU OTA transfer using nRF Connect for Desktop v3.4.2, it failed (hard faulted on embedded side).

Here is the error (the last part):

2020-08-04T20:38:29.543Z DEBUG      297 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:2 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.543Z DEBUG  time:2020-08-04T20:38:29.545Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 count:1
2020-08-04T20:38:29.544Z DEBUG      298 ->  [00 9c 00 00 01 01 00 0f 00 00 00 01 00 01 03 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:2 payload_length:f data_integrity:1 header_checksum:2b err_code:0x0
2020-08-04T20:38:29.578Z DEBUG   295/ 0 <-  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.578Z DEBUG   296/ 0 <-  [01 9c 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:2 ack#:0 payload_length:6 data_integrity:1 header_checksum:d0 err_code:0x0
2020-08-04T20:38:29.578Z DEBUG      299 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:3 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.611Z DEBUG   297/ 0 <-  [02 38 00 00 00 00 00 00 00 0f 00 01 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:3 ack#:0 payload_length:10 data_integrity:1 header_checksum:2e err_code:0x0
2020-08-04T20:38:29.611Z DEBUG      300 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:4 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.612Z DEBUG GATTC_EVT_WRITE_RSP time:2020-08-04T20:38:29.612Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 writeOp:1 offset:0 len:0
2020-08-04T20:38:29.612Z INFO Attribute value changed, handle: 0x0F, value (0x): 03
2020-08-04T20:38:29.644Z DEBUG   298/ 0 <-  [02 39 00 00 00 00 00 00 00 0f 00 01 0b 00 60 03 01 8d 00 00 00 1f 9f e7 a6 ] type:     VENDOR_SPECIFIC reliable:yes seq#:4 ack#:0 payload_length:19 data_integrity:1 header_checksum:9d err_code:0x0
2020-08-04T20:38:29.644Z DEBUG      301 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:5 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.645Z DEBUG GATTC_EVT_HVX time:2020-08-04T20:38:29.645Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 type:1 len:11
2020-08-04T20:38:29.645Z INFO Attribute value changed, handle: 0x0F, value (0x): 60-03-01-8D-00-00-00-1F-9F-E7-A6
2020-08-04T20:38:29.650Z DEBUG      302 ->  [00 9c 00 00 01 01 00 0f 00 00 00 01 00 01 04 ] type:     VENDOR_SPECIFIC reliable:yes seq#:0 ack#:5 payload_length:f data_integrity:1 header_checksum:1a err_code:0x0
2020-08-04T20:38:29.683Z DEBUG   299/ 0 <-  [N/A] type:                 ACK reliable: no seq#:0 ack#:1 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.683Z DEBUG   300/ 0 <-  [01 9c 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:5 ack#:1 payload_length:6 data_integrity:1 header_checksum:c5 err_code:0x0
2020-08-04T20:38:29.683Z DEBUG      303 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:6 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.716Z DEBUG   301/ 0 <-  [02 38 00 00 00 00 00 00 00 0f 00 01 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:6 ack#:1 payload_length:10 data_integrity:1 header_checksum:23 err_code:0x0
2020-08-04T20:38:29.716Z DEBUG      304 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:7 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.716Z DEBUG GATTC_EVT_WRITE_RSP time:2020-08-04T20:38:29.717Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 writeOp:1 offset:0 len:0
2020-08-04T20:38:29.716Z INFO Attribute value changed, handle: 0x0F, value (0x): 04
2020-08-04T20:38:29.860Z DEBUG   302/ 0 <-  [02 39 00 00 00 00 00 00 00 0f 00 01 03 00 60 04 01 ] type:     VENDOR_SPECIFIC reliable:yes seq#:7 ack#:1 payload_length:11 data_integrity:1 header_checksum:12 err_code:0x0
2020-08-04T20:38:29.861Z DEBUG      305 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.861Z DEBUG GATTC_EVT_HVX time:2020-08-04T20:38:29.862Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:15 type:1 len:3
2020-08-04T20:38:29.861Z INFO Attribute value changed, handle: 0x0F, value (0x): 60-04-01
2020-08-04T20:38:29.873Z DEBUG      306 ->  [00 9c 00 00 01 01 00 0f 00 00 00 02 00 01 06 02 ] type:     VENDOR_SPECIFIC reliable:yes seq#:1 ack#:0 payload_length:10 data_integrity:1 header_checksum:30 err_code:0x0
2020-08-04T20:38:29.905Z DEBUG   303/ 0 <-  [N/A] type:                 ACK reliable: no seq#:0 ack#:2 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:29.906Z DEBUG   304/ 0 <-  [01 9c 00 00 00 00 ] type:     VENDOR_SPECIFIC reliable:yes seq#:0 ack#:2 payload_length:6 data_integrity:1 header_checksum:c2 err_code:0x0
2020-08-04T20:38:29.906Z DEBUG      307 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:1 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:49.901Z DEBUG   305/ 0 <-  [02 11 00 00 00 08 ] type:     VENDOR_SPECIFIC reliable:yes seq#:1 ack#:2 payload_length:6 data_integrity:1 header_checksum:c1 err_code:0x0
2020-08-04T20:38:49.901Z DEBUG      308 ->  [N/A] type:                 ACK reliable: no seq#:0 ack#:2 payload_length:0 data_integrity:0 err_code:0x0
2020-08-04T20:38:49.901Z DEBUG GAP_EVT_DISCONNECTED time:2020-08-04T20:38:49.903Z connHandle:0 reason:8 reasonName:connectionTimeout
2020-08-04T20:38:49.902Z DEBUG Destroying DFU transport.
2020-08-04T20:38:49.902Z ERROR DFU failed with error: When writing 'SELECT' command to Control Point Characteristic of DFU Target: Could not write SELECT command: Device disconnected.

Is there any hope it can still work, considering ATT_MTU example works? What error is at address 0x00014AA6?

UPDATE: I found this https://devzone.nordicsemi.com/f/nordic-q-a/47171/softdevice-assertion-failed-at-0x00014aa6

Which led me to this: https://devzone.nordicsemi.com/f/nordic-q-a/40088/sd_flash_write-cause-nrf_fault_id_sd_assert

It seems that SD v7.0.1 has a longer time allocated for flash operation, that's why it works.

Theoretically speaking, I can do the work around (split half-size for the write) and make v6.1.1 works.

Could you confirm if this is indeed the issue?

As I am not sure how SD scheduling works, I want to make sure I implement the workaround at the right place to be effective (to be able to return the time slice). Is it in nrf_dfu_settings_svci.c in any occurences of sd_flash_write()? Or is it in nrf_dfu_flash.c, in the nrf_dfu_flash_store()? Or is it somewhere else?

Also, for the flash erase, the minimum size is one page. Is the workaround splitting erase one page at a time and add delay in between?

[Hung Bui]

Hi Harry, 
It's not recommended to use S140 v6.1.1 with SDK17.0.0 (unless you really know what needed to modify) 

What I would suggest you to either move to S140 v7.0.1 or modify the DFU example in SDK v16 to support nRF52833. You can do a compare between the nRF52833 DFU project in SDK v17 to the nRF52840 DFU project in SDK v17 to see what modification needed to convert the nRF52840 project in SDK v16.0 to nRF52833. 

Our softdevice need to pass through very intensive testing and qualification process so I would strongly suggest you to move to the latest softdevice. The issues in the link have been fixed in S140 v7.0.1.

How often do you see the DFU process failed ? 

[Harry]

Hi Hung,

Thank you so much for the answer and insight.

Hung Bui said:

How often do you see the DFU process failed ? 

The DFU process failed every time.

[Hung Bui]

I think it's the best if you can move to S140 v7.0.1 and test with the stock example we have.