This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Creating custom op-code for the DFU

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.

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

Related