Creating custom op-code for the DFU

[PF-JohnF]

Hello,

I'm currently working on a custom DFU op-code that allows the MCU to send a "pause" op-code, similar to the op-codes found in the DFU protocol.

The steps I've taken to complete this are following cloning the pc_nrfconnect_ble (v2.5.0) repository, eventually finding that the code that runs the DFU is actually pc-ble-driver-js, and digging through the JS to somewhat figure out what's going on.

I also understand that I'm going to have to modify the secure_bootloader example that runs on the NRF52832 to make sure that it can send the op-codes.

So here are my questions:

Would it be better for me to create a custom service that is a "pause" operation to future-proof my code in case Nordic desides to add more op-codes to the DFU, overwriting the ones that I have? I am somewhat against this idea because it really only makes sense to me for the DFU to have only one service that does all of the controlling.

Is there a guide to set up the environment to compile the pc-ble-driver-js? If I'm not mistaken the README on the Github repository says that one can install a binary using npm, but I would need to be able to compile the code that I've modified and I haven't found a guide on how to do this.

And finally, is there a way that one can change the number of bytes are sent before a CRC is transmitted back to the back to the host device? The variable is inside of pc-ble-driver-js, dfuModels.js, and the value is "maximumSize" inside of the deviceState in the constructor of the FirmwareState class. I can't find where the variable is set though. Is it transmitted from the NRF52832? Or is it just a constant somewhere else in the pc-ble-driver-js package? I remember seeing something about protoc but I couldn't find anything about it recently.

Thanks in advance for the help, and if there's anything else I need to state to help narrow down problems please let me know.

[Edvin]

Hello,

I think that you need to start by looking into nrfutil, as this is the default tool used to connect to, and perform DFU. I have never compiled it myself. You would also need to implement the new opcodes in the bootloader FW.

Why do you want to pause it? What should happen when you pause the DFU process? Do you need it to start the previous application again?

Best regards,

Edvin

[PF-JohnF]

We are developing an energy harvesting board that is very low power (<100uA). The energy storage on board is around 500uF and we can't guarantee a set current into the capacitors. When the capacitors get low they will trigger an event that will alert the DFU to pause so the capacitors can charge back up and then resume normal DFU operation once above a certain voltage.

The previous application only needs to be started again if the DFU process fails or is aborted. The previous application does not need to be started if the DFU is paused so the capacitors can regain charge.

I will look at nrfutil, but I haven't been able to get the OTA BLE operation to work using nrfutil in the past.

[Edvin]

So let me see if I understand:

The DFU target is the energy harvesting board, right?

By default, the bootloader and nrfutil is supposed to handle disconnects, but the behavior depends on the bootloader projects sdk_config.h settings. 

There is a setting called NRF_DFU_SAVE_PROGRESS_IN_FLASH. It saves the progress, and currently received image in flash. When the device runs out of power, it will continue from where it left off when it resumes. This is initially intended in case of disconnects, but I guess it will work in your case as well. The amount of data that is received before storing it in flash is determined by the definition NRF_BL_FW_COPY_PROGRESS_STORE_STEP.

Test it out and see if that is something that you can use, and if this is sufficient. If not, figure out what you need in addition to this. Perhaps you don't need to change anything in nrfutil at all.

 

PF-JohnF said:

I will look at nrfutil, but I haven't been able to get the OTA BLE operation to work using nrfutil in the past.

 I guess you already use nrfutil to generate the DFU images. To perform the DFU using nrfutil you need an extra DK/dongle, and you perform the update by using:

nrfutil dfu ble ...

Use the command "nrfutil dfu ble --help" to see the options that you have.

Best regards,

Edvin

[PF-JohnF]

You are correct that the DFU target is the energy harvesting board.

We are already using the NRF_DFU_SAVE_PROGRESS_IN_FLASH setting, which is super useful when the DFU does not reach completion due to timeouts or the power running out. I had not seen anything relating to NRF_BL_FW_COPY_PROGRESS_STORE_STEP, but I will test it out.

However the issue that we are trying to avoid is a reboot, because this means that the user initiating the DFU will have to reconnect to the DFU target, select the file, and resume the DFU.

What we are proposing is instead the DFU can pause and still be connected to the device that initiated the DFU. That way there is less user input and the process is more automatic once initiated.

Going back to what I asked in the original post, would it be better to add to the DFU op-codes, or should I instead add a custom service?

Thank you for your help thus far.

[Edvin]

Hello,

So you are using a computer to perform the DFU, right? And you want to create your own version of nRF Connect for Desktop?

I don't know if we are the best to help you with javascript. And if you are only going to use it for DFU, perhaps it is a bit overkill. I suggest you look into nrfutil. We mostly work on the applications on the nRF, and we don't have many people working with javascript, apart from the team that writes these tools for us. If you want to build nRF Connect for Desktop on your own, I suggest you see if you can find someone who is experienced with javascript.

 

PF-JohnF said:

However the issue that we are trying to avoid is a reboot, because this means that the user initiating the DFU will have to reconnect to the DFU target, select the file, and resume the DFU.

 That of course depends on the application performing the DFU, and what it does when the device disconnects. If it just starts looking for the same device that it disconnected from, and then resume the operation with the same application image when it reconnects, the user doesn't have to do anything. 

I thought that the device would turn off because it ran out of power, as it is an energy harvesting device? But perhaps I misunderstood.

I believe the easiest workaround if you need the pause functionality is to add a custom characteristic that you can write to, that the DFU master (the device that performs the DFU on the DFU target) can enable notifications on, and then pause the update when it receives a message saying so. However, you would still need to modify nRF Connect for Desktop or nrfutil.

In case you are a company that works mostly with embedded FW, I suggest you look into the implementation of nrfutil. Either way, I suggest you try it out to perform a regular dfu on a DK, to see how it is workin.

Best regards,

Edvin

[PF-JohnF]

I would agree with you that making a modified version of NRF connect is somewhat overkill. We might instead modify nrfutil with a custom characteristic like you stated.

I assumed that all the DFU programs didn't try to reconnect to the device if something went wrong, such as a power outage or an error. I'll have to make sure that nrfutil doesn't do this, because the best temporary solution may be to decrease the NRF_BL_FW_COPY_PROGRESS_STORE_STEP size and allow the DFU to autoreconnect when it powers off.

Your suggestions have been very helpful, and we really appreciate it. Thank you.