Making a DFU controller: how to properly handle [DFU] Invalid system components (send 04, recv 60-04-0A)?

RE: Making a DFU controller: how to properly handle [DFU] Invalid system components (send 04, recv 60-04-0A)?

Hung Bui — Tue, 10 Sep 2019 12:15:22 GMT

Hi SCLA,

I haven't tried to reproduce the situation that you described. But as far as I remember, the SD+BL+APP is done as it's 2 separated DFU update, first with SD+BL and then a normal APP update. So what you described of the behaviour of the nRFConnect app seems to match with my understanding.

RE: Making a DFU controller: how to properly handle [DFU] Invalid system components (send 04, recv 60-04-0A)?

scla — Mon, 09 Sep 2019 17:30:36 GMT

Thanks for the replies.

In this case, I'm not sure how knowing the exact problem will help. My DFU controller is able to successfully transfer DFU packages to DFU Targets. But I am attempting to make my custom DFU controller robust to handle issues that may arise. As far as I am aware, the DFU controller would only ever receive these response codes, "operation not permitted," and so would need to know how to resolve the issue with only having this information.

So I see the nRFConnect utility will resolve this issue just from the response code. For eg., when I put the DFU Target into this bad state (by forcibly disconnecting my controller from the DFU target after the SDBL is sent and before any bytes from the application are sent), I will then attempt to DFU with nRFConnect over my Android phone. nRFConnect sends 0x04 and receives 60-40-0a. I see a '[DFU] Invalid System Components' log, then it proceeds to resolve the issue and uploads the application. Am I wrong in believing there is a straight-forward protocol for handling ALL "x040a" and "operation not permitted" response codes? If I am, how does the nRFConnect app know how to handle this response?

I can still look into this though.

Edit -

Following the nRFConnect logs when the controller resolves the issue, it looks like it 'forces' upload of the app init packet. It will send a select command, receive the offset and crc of the EOF of the SDBL init packet, ignore these values, and start sending the app init packet bytes to the DFU packet char.

Trying this in my custom DFU controller, it seems to 'work' in that the application successfully transfers and runs.

RE: Making a DFU controller: how to properly handle [DFU] Invalid system components (send 04, recv 60-04-0A)?

Hung Bui — Mon, 09 Sep 2019 14:21:31 GMT

Hi Scla,
If you have a look here https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v12.3.0/lib_dfu_transport_ble.html?cp=5_5_7_3_5_2_2

You can find that 0x08 response code is

Operation not permitted

The state of the DFU process did not allow this operation.

If you have a look at NRF_DFU_OBJECT_OP_CREATE case in nrf_dfu_data_req() inside dfu_req_handling.c you can see several situations that it would return NRF_DFU_RES_CODE_OPERATION_NOT_PERMITTED.

I agree with Jorg, you should build the bootloader with debug logging enabled, much more information for testing.

RE: Making a DFU controller: how to properly handle [DFU] Invalid system components (send 04, recv 60-04-0A)?

Turbo J — Sat, 07 Sep 2019 12:56:18 GMT

I recommend looking at the source code in the SDK directly.

You can build a debug version of the bootloader with debug symbols and RTT logging. Only disadvantage: It will be MUCH bigger than the non-debug one (adjusting bootloader addr in UICR required).