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

[scla]

Hi,

I'm developing a BLE DFU controller with bluepy on a RPi3. The peripheral that is being updated is a nRF51 device on SDK 12.3.0, with the secure bootloader and experimental buttonless DFU service.

The script seems to DFU perfectly fine, and now I want to properly handle any faults/errors that can occur during the DFU process.

One big issue that I'm having occurs when I stop the DFU process after uploading the softdevice and bootloader completely, but before I've uploaded anything from the application. On the next connection to the Nordic device, when I select the init packet ([06 01]) I receive the offset for the length of the softdevice bootloader init packet. When I attempt to send the application OR the softdevice BIN file, on create object commands I receive responses [60 01 08]. I cannot seem to find anywhere in the documentation what error code '08' represents (unless I'm mistaken, this only goes up to 6?). 

Here are some of my generated logs from my script:

   sd_bl.dat
   [WRITE]          ctrl --> 02 00 01
   [RESPONSE]       recv <-- 60 02 01
   [WRITE]          ctrl --> 06 01
   [RESPONSE]       recv <-- 60 06 01 00 01 00 00 95 00 00 00 a7 c8 66 94
   [DFU]            crc32.match.
   [WARNING]        image.previously.sent..
   [WARNING]        initiating.execute.as.precaution
   [WRITE]          ctrl --> 04
   [RESPONSE]       recv <-- 60 04 0a
   [WARNING]        error.response.opcode.4
   [WARNING]        error.response.result.10

   # Note that the below happens with application.dat too!
   sd_bl.bin 
   [WRITE]          ctrl --> 02 00 01
   [RESPONSE]       recv <-- 60 02 01
   [WRITE]          ctrl --> 06 02
   [RESPONSE]       recv <-- 60 06 01 00 10 00 00 00 00 00 00 00 00 00 00
   [WRITE]          ctrl --> 02 00 01
   [RESPONSE]       recv <-- 60 02 01
   [WRITE]          ctrl --> 01 02 00 10 00 00
   [RESPONSE]       recv <-- 60 01 08

I re-created the 'bad state' of the device as above and then used a phone with nRFConnect to DFU the device to see how this should be handled. Here are the logs I see:

[DFU] Notification received from [...], value (0x): 60-04-0A
[DFU] Invalid system components. Trying to send application.
Data written to [...], value (0x): 06-01
Data written to [...], value (0x): 02-00-00
Data written to [...], value (0x): 60-01-01

.. (now sends data objects) ..

However I tried sending these exact commands ([06, 01], [02, 00, 00], [60, 01, 01]) but still get the same response [60, 01, 08].

Any ideas or guidance on what is happening and how to handle this? I'm sure I'm missing something really simple in the protocol.

[Turbo J]

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).

[Hung Bui]

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. 

[scla]

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.

[Hung Bui]

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.