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]

Hi,

Please see this post.

[brianreinhold]

Confidence is low. Either it is much harder than the line 'add the trigger library' in the documentation (there is little else so one is lead to believe that it is very easy) or I am really missing something.

[brianreinhold]

Okay. So if I copied my application code into examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci

that should provide the necessary trigger support? I just got overwhelmed going the other way and never reached the end of adding more c files and include files never mind the sdk_config.h 90% of which I do not know what it does.

[Einar Thorsrud]

In that case you would have the required libraries, drivers and sdk_config.h configurations in place, yes. There will probably be other adaptations needed for your project though, but this may be the simplest approach.

[brianreinhold]

Okay, now that I am going to try and make the merge between this 70K DFU and my 10K app, I have not been able to find any documentation about this example. So how does it work? There is BTLE stuff in the project. Does that mean the huge USB stuff is just to enter DFU mode and the actual download of the application is via Bluetooth?

If there IS documentation for this example somewhere, it would be great if you could tell me where it is.

Thanks

[Einar Thorsrud]

brianreinhold said:

Okay, now that I am going to try and make the merge between this 70K DFU and my 10K app, I have not been able to find any documentation about this example. So how does it work?

The ble_connectivity project? It demonstrates serialization, so you can refer to the serialization documentation. From what I understand you don't actually need this project, you just wanted to start with project files that has the needed dependencies for the USB DFU trigger library, is that still the case? If so, I guess the details of serialization is not relevant, as you are anyway going to strip that away.

brianreinhold said:

here is BTLE stuff in the project. Does that mean the huge USB stuff is just to enter DFU mode and the actual download of the application is via Bluetooth?

No, it does not mean that. This project is intended so that one device can send SoftDevice API commands over a serial interface (like USB) to use the device running this example as a connectivity IC. So this example use both USB and bluetooth. The example code itself does not do DFU at all, as that is handled by the bootloader. But it uses the USB DFU trigger library to enter DFU mode via USB. That is really the only thing this project does that is relevant for you as far as I understand it.

[brianreinhold]

So this is for the pc-ble-driver. The first thing I ever did with Nordic hardware was use the pc-ble-driver (and the system info restore on a bonded reconnect bug is still there)- I wrote test suites for BT-SIG profile health device clients - that is why all my current projects use SoftDevice only for BTLE as with the pc-ble-driver that's all you can use. I like working with SoftDevice only, however, as the Bluetooth is the only part of all this stuff I have a decent understanding of.

So what you are saying is all the way at the beginning. I have to hunt and peck for all those c-files and h-files and sdk_config.h options. If I do that I then can use the NRF Connect as the DFU client (or whatever the sender of the updated code is called).

There has go to be a feasible way to do this. Those c-files are all over the place throughout the SDK, and the errors you get are missing methods - which doesn't help you find the c-file.Wonder if it would be possible to hack into the SES or Keil project files though I still wouldn't know which of them were relevant for for the trigger. It is far more than just USB as I found out.

[Einar Thorsrud]

brianreinhold said:

So what you are saying is all the way at the beginning. I have to hunt and peck for all those c-files and h-files and sdk_config.h options.

Yes. That is not very fun work but that is how it is in the nRF5 SDK. (In the nRF Connect SDK most of this is automated using CMake).

brianreinhold said:

There has go to be a feasible way to do this.

Yes. The best approach is to look at an example and add what you think are relevant C files, include directories and sdk_config.h sections. After that try to build and fix errors as you go.

brianreinhold said:

the errors you get are missing methods - which doesn't help you find the c-file.

It is the opposite, actually. You just have to search for what is missing to see which file it is defined in. Then you probably have not included the file, or is missing an sdk_config.h define that makes the preprocessor remove what you need. 

[brianreinhold]

Well, here I go again. Since my app uses no USB, I take it I am NOT shared

//==========================================================
// <h> nrf_dfu_trigger_usb - USB DFU Trigger library

//==========================================================
// <q> NRF_DFU_TRIGGER_USB_USB_SHARED - Flag indicating whether USB is used for other purposes in the application.

#ifndef NRF_DFU_TRIGGER_USB_USB_SHARED
#define NRF_DFU_TRIGGER_USB_USB_SHARED 0
#endif

// <o> NRF_DFU_TRIGGER_USB_INTERFACE_NUM - The USB interface to use for the DFU Trigger library. <0-255>

// <i> According to the USB Specification, interface numbers cannot have
// <i> gaps. Tailor this value to adhere to this limitation.

#ifndef NRF_DFU_TRIGGER_USB_INTERFACE_NUM
#define NRF_DFU_TRIGGER_USB_INTERFACE_NUM 1
#endif

I finally got it to build. Copy path between two instances of SES and KEIL was the savior here. The final size went only to 22K from 10K which wasn't so bad BUTit did not work. The APP worked, but nRF Connect stated no Nordic DFU Trigger library found. So all that was pointless.

[Einar Thorsrud]

Hi,

brianreinhold said:

The APP worked, but nRF Connect stated no Nordic DFU Trigger library found. So all that was pointless.

It seems like you have done a good part of the job now, so I it should not be pointless even though apparently something is missing. 

Did you remember to initialize the USB driver and DFU trigger library, similarly to how it is tone in examples/connectivity/ble_connectivity/main.c?

[brianreinhold]

There are a lot of opens. I thought I only had to call the triigger init method in my app. But I have been looking at others who have had problems and there are all kinds of things I still don't know about. Some posts are old enough they might no longer apply.

 BOARDS_WITH_USB_DFU_TRIGGER  being one

The SHARED and INTERFACE number for another

and I do not have USB in my original app so it looks like I have to do those usb init and unsb enable and callbacks for events. I will have an additional challenge as I handle events myself in the infinite for loop

[Einar Thorsrud]

Hi,

I see. For instance BOARDS_WITH_USB_DFU_TRIGGER is used by the BSP to call nrf_dfu_trigger_usb_init() for you during bsp_board_init(). If you do not use the BSP (which I assume not, as  you seem to prefer to avoid as many libraries as possible?), then you call nrf_dfu_trigger_usb_init() directly in your code instead, as is done in the ble_connectivity example.

If you do not use USB for anything else, NRF_DFU_TRIGGER_USB_USB_SHARED should be 0.

Note that if this case a lot of problems and you have another way of communicating with your app, you could also use a custom way to enter DFU mode. As long as you are able to tell your application that it should enter DFU mode in one way or another (the DFU trigger library implementing one of them via USB), then actually entering DFU mode is straight-forward.