How to use the trigger library to program the nRF52840 dongle

[brianreinhold]

Sorry but I find the documentation useless. I don't even know where to start. It could be I have not found the correct documentation which is not surprising.

The best I have is this: https://devzone.nordicsemi.com/f/nordic-q-a/77254/nrf52840-dongle-pca10059-dfu-trigger-library/332347#332347

but I have no idea how this even started.

Right now the project works. I can use the reset button to flash the dongle and it works. Its a BTLE peripheral that a cycle power client connects to at which time the device starts a scanner and gets data from an unconnectable advertisement from a bike and notifies the data to the client. The USB is used only as a source of power. The project uses SoftDevice for BTLE and flash writes and not the SDK.

Now I want to add the overhead to be able program the dongle without touching the reset button. I don't know where to start. It's clear I have to add lots of h-files and c-files to the project. However, where do I find the steps that document how one adds this functionality to an existing project?

• What methods do I need to call and when?
• What configuration parameters do I need to set outside of sdk_config.h?
• What configuration parameters do I need to set in sdk_config.h?
• Where are these methods and h-files located so I can pull/configure my project?

One final question, how much overhead does this add? Will it greatly increase the size of my executable project?

When and if this ever gets completed, would that mean I can flash the dongle directly from Keil or Segger or do I still need nRF_Connect that I use now where I have to press the reset button?

[Einar Thorsrud]

I am not sure exactly what information/documentation you seek. There is no specific tutorial for adding the DFU trigger library to an application that does not use USB from before, so you have to do this yourself. There is nothing special about the DFU trigger library here, so you should do the same there as with other modules/libraries. In practice this is not hard though, as you generally just have to correct compiler errors and warnings along the way, but it a bit tedious an annoying. This is the same as for adding other libraries/modules.

brianreinhold said:

The huge overhead will probably also mean a corresponding cost in power - memory alone.

I do not see how flash usage itself increases power consumption.

brianreinhold said:

It there alternative approaches to programming the dongle without pressing the reset and using the USB (imagine the dongle in a sealed shell so you are stuck with the USB)?

Yes and no. If you build a bootloader that has NRF_BL_DFU_ENTER_METHOD_GPREGRET set to 1 in the bootloader's sdk_config.h that will allow you to enter bootloader mode by simply writing a magic word to the retention register and doing a soft reset. If you are using the USB bootloader that shipped with the dongle without any modification that does not work, but in this case you can trigger DFU mode by asserting pin reset using a GPIO connected to the reset pin. See the handling of APP_USBD_NRF_DFU_TRIGGER_USER_EVT_DETACH in components\libraries\bootloader\dfu\nrf_dfu_trigger_usb.c. In any case you would need a method to tell your firmware that it should enter DFU mode though. We provide the DFU trigger library to do this via DFU, but if you have another method of communication you can use that as well (UART, BLE, whatever).

[brianreinhold]

If I add the BLE DFU to talk to my application and do all that other stuff you mentioned above, how do I get my application onto the dongle? I cannot press the reset button.

Another  hurdle - no documentation on

\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci\

There is no documentation on any of the examples in 'connectivity' as far as I can tell. I don't even know what this example is supposed to do.

[Einar Thorsrud]

Hi,

brianreinhold said:

If I add the BLE DFU to talk to my application and do all that other stuff you mentioned above, how do I get my application onto the dongle? I cannot press the reset button.

For buttonless DFU you want the buttonless DFU service. That is demonstrated by the Buttonless DFU Template Application.

brianreinhold said:

\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci\

The examples under \examples\connectivity\ble_connectivity\ are intended to be used when the nRF is a connectivity device. Then the SoftDevice APIs are exposed via a serial interface (typically UART or SPI). This is for instance the basis for the connectivity firmware used by the pc-ble-driver, though that patches the example extensively. There are also some other examples that are in folders starting with "ser_" and these are then for the host side, so that you use these examples on one DK, and the connectivity firmware on another. You can refer to the Serialization documentation as well as Running a serialized application if you want to know more about this.

[brianreinhold]

Okay, I am getting so confused here let's fall back on what I need to do. I think there have been a number of rabbit holes that have been entered and now I don't know where I am.

The problem sounds simple. I have a BTLE application which works on the nRF52840 DK and the nRF52840 dongle. The only problem is that I have to press the reset button in order to install my application and SoftDevice onto the dongle. In addition, I must use the nRF Connect Programmer to install. (This is far superior to be forced to use a command line implementation.)

What I want to be able to do is to install my application and all the support software onto the dongle without ever pressing the reset button. I don't want to have to push the reset button the first time I program the dongle or the Nth time I program it.

In addition, If I use the nRF Connect Programming app it does not see the dongle unless the reset button is pushed. But I cannot access the reset button. Is there a way around that?

Okay, maybe its going to cost me downloading a 70-80K support application in order to use a 10K application though I am still unclear as to how to do that. It appears that some simply install a separate app that is only a DFU and then they install their app in addition; That does sound easier than messing up my app with trigger support given that the trigger support code is so huge it completely obscures my stuff. A three-app solution sounds better (1) SoftDevice (2) DFU (3) My application. Easier to maintain as well.

[Einar Thorsrud]

Hi,

brianreinhold said:

What I want to be able to do is to install my application and all the support software onto the dongle without ever pressing the reset button. I don't want to have to push the reset button the first time I program the dongle or the Nth time I program it.

I see. So the question about BLE was not relevant then? I assume USB DFU is the only thing you want. In that case, you can ignore what I wrote about the buttonless DFU service and Buttonless DFU Template Application in my previous reply.

brianreinhold said:

In addition, If I use the nRF Connect Programming app it does not see the dongle unless the reset button is pushed. But I cannot access the reset button. Is there a way around that?

The workaround for that is to include the DFU triggers library, as we have discussed before. That is designed for this exact use case.

brianreinhold said:

Okay, maybe its going to cost me downloading a 70-80K support application in order to use a 10K application though I am still unclear as to how to do that. It appears that some simply install a separate app that is only a DFU and then they install their app in addition; That does sound easier than messing up my app with trigger support given that the trigger support code is so huge it completely obscures my stuff. A three-app solution sounds better (1) SoftDevice (2) DFU (3) My application. Easier to maintain as well.

I am not sure why that would be easier. Most of the USB related stuff here would be isolated to SDK libraries and drivers, and you can make a clear separation between this and the rest of your application. The SDK bootloader does not support multiple apps. Also, I do not see how multiple apps would support this. You would need a method to trigger the other app then, which should in turn trigger DFU mode. But if you have a method to trigger the new app, then you could just trigger DFU mode instead. So this would just complicate things much more and not bring any value. This reminds me to re-iterate an important point: There is no need for you to use the DFU trigger library to trigger bootloader mode if you do not want to. You can use any method, as long as you are able to inform your application somehow that it should enter DFU mode, then actually entering DFU mode is a simple task.