Custom board USB DFU (buttonless)

[edition]

Trying to add the capability of USB DFU (buttonless, because I forgot to have a button for it) to my custom board (nrf52840, MS88SF31 module). Reading about this process from different places gives different answers and I can't quite wrap my head around it. I have made a custom board and managed to program a LED to blink. For programming I used openocd and ST-link 2. 

If anyone can lead me in the right direction, help would be appreciated. I have read the academy course on it, and some documentation as well but a lot of the terminology is lost on me.

Biggest questions I have with it are:
1. Where do I get the MCUBoot? I have managed to build one through visual studio code with my application, but it didn't seem to work, I don't really know how to test it other than connect the board through USB and look at NRF Connect for Desktop, Programmer. I have also seen a lot of mentions of pca10040 pca10100 etc., but I don't understand what am I suppose to do with the stuff in those folders. All the file types are completly different from the ones that I have seen before.

2. If I manage to get the USB DFU to work, can I program my board through NRF Connect for Desktop, Programmer or do I need something else? 

3. How much, if at all, do I need to change the bootloader? As I understand, I need to add a few lines to make the DFU USB work, but is there something else I need to do aswell? I have read about mcumgr, which I don't really understand the purpose of I this context.

Thanks in advance!

[nordicator_prim3]

Yeah, I remember starting with DFU and MCUboot and having a rough time haha. These aren't complete answers but I think it will get you moving in the right direction. Everything I talk about below can be seen in the SMP Server example built into Zephyr. So you should just be able to build that, flash it with the programmer once, then test DFU.

1. MCUboot is included in Zephyr, you "get" it by using Kconfig options to include it in your build and make any configuration changes to the bootloader. Testing MCUboot will not involve NRF connect or the programmer; it will only involve a client (like mcumgr) that uses USB in your case. The programmer lets you write anywhere in memory while MCUboot and the DFU process is essentially for making sure you only affect your application binary and not the bootloader binary. Another easy way to test (if you have bluetooth) is to add some extra kconfig to hook mcuboot up to bluetooth and use the NRF Device Manager phone app.

2. If you want to test DFU and only update your application code it would not involve NRF Connect or the programmer. There are many clients that can talk to mcuboot. One you mentioned is mcumgr command line tool. I've used that to test DFU over USB and it worked fine. MCUboot is expecting something to talk to it with the SMP protocol. mcumgr (and many other programs) already speak SMP protocol so you don't need to learn how to speak it. Another example is the python package SMPClient which can use USB; using this is more involved though and I would recommend mcumgr for quick testing).

3. You (usually) don't need to "change" the bootloader at all. Virtually any change you need to make can be done with Kconfig statements. In the SMP server example, all you have to do is enable your USB port in your application code and it should work. All the bootloader does is check if there's a pending firmware update, handle it if so, and then point to the first memory address of your application code. Your application code just needs to know to enable the usb port.

In short, check out the SMP server example and maybe try this video out. Hopefully this helps!