How to use the trigger library to program the nRF52840 dongle

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Mon, 01 Nov 2021 08:48:29 GMT

Once I got it to build and it still didn't work I thought it was time for a new thread. Turns out there are some additional problems I don't understand that need to be addressed in order for the USB to enumerate on Windows. I also had competition on the handling of the SoftDevice sd_app_evt_wait()/get() mehtods.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Mon, 01 Nov 2021 08:42:09 GMT

Hi,

I see you are deeper into this discussion in this thread, so I suggest continuing there instead of speeding the discussion across multiple threads.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Fri, 29 Oct 2021 09:35:30 GMT

Einar,

where I avoid the SDK is with respect to Bluetooth. It's the only part of all this material I have any understanding of. Personally I find it much easier to use the basic GATT/GAP concepts (which I understand and know) provided by SoftDevice than trying to learn the SDK. In addition, I am working on a new standard and there is no support for it in the SDK. I also needed to work with multiple different versions of the Nordic MCUs and the changes in the SDK were huge whereas the changes in SoftDevice were not. That makes my code easier to port. Lastly, I started all this work using the pc-ble-driver and you had no choice but to use SoftDevice. I wrote a series of test suites for clients that supported the BT-SIG health device profiles and got quite familiar with SoftDevice.

This new standards project came a year later and to me it was very important to see how difficult it is to implement this new standard on real embedded systems - not mock ones on a PC with its powerful OS. But I am no embedded programmer. Have little experience, So with respect to everything else but GATT/GAP, I 100% rely on these examples to get the MCU up and running so I can do Bluetooth.

So long story short - YOU BET I USE BSP!

Okay - so back to DFU (again which I do not have a good understanding of how it works with this GPIO and stuff).

I set shared to 0, and therefore I assume my interface number is 0 as this is the first one.

In the connectivity example I see two USB callbacks - one in main (usbd_user_evt_handler) and another one in the trigger library code (usbd_user_evt_handler). I assume the one in main is for serializing data over USB such as with the pc-ble-library. If I can use the BOARDS_WITH_USB_DFU_TRIGGER option and have my bsp_board_init() call do all the setup work including initializing USB I am a happy camper!

My concern is that I also had to take over the handling of events by using

sd_app_evt_wait(0 and sd_ble_evt_get() in my main for(;;) loop that every example calls because my data stream was longer than a MTU and had to be fragmented. I fell onto situations where I had to wait for the TX queue to empty and since there was no semaphore support the only way to do an efficient wait was sd_app_evt_wait(). That really shook up my code design! But I have gotten it to work and have been using it for quite a while now.

So with this DFU, will my sd_app_evt_wait() and sd_ble_evt_get() conflict with the soc library's use of sd_evt_get()? I note the connectivity app also 'clears' some registers in the on_idle() call in main(). I do not understand this.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Fri, 29 Oct 2021 07:57:58 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Thu, 28 Oct 2021 14:08:09 GMT

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

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Thu, 28 Oct 2021 12:44:44 GMT

Hi,

[quote user="brianreinhold"]The APP worked, but nRF Connect stated no Nordic DFU Trigger library found. So all that was pointless.[/quote]

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?

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Thu, 28 Oct 2021 10:54:02 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Thu, 28 Oct 2021 08:56:45 GMT

[quote user="brianreinhold"]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. [/quote]

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

[quote user="brianreinhold"]There has go to be a feasible way to do this.[/quote]

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.

[quote user="brianreinhold"]the errors you get are missing methods - which doesn't help you find the c-file.[/quote]

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Thu, 28 Oct 2021 08:42:40 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Thu, 28 Oct 2021 06:23:08 GMT

[quote user="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?[/quote]

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.

[quote user="brianreinhold"]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?[/quote]

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Wed, 27 Oct 2021 15:24:35 GMT

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

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Mon, 25 Oct 2021 12:05:15 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Mon, 25 Oct 2021 11:09:42 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Mon, 25 Oct 2021 09:16:18 GMT

Hi,

[quote user="brianreinhold"](I still have not figured out how to make quotes like you have done.)[/quote]

When you highlight text there is a "Quote" button you can press to quote:

[quote user="brianreinhold"]So if I understand you correctly, even though my app is NOT YET INSTALLED on the dongle, by including the trigger library and all the usb and related stuff around it into my app I will be able to install this app onto the dongle without pressing the reset button - even though the nRF COnnect programmer does not see the dongle. I don't understand how that will work![/quote]

No. Clearly, any discussion about what you can do from your app only applies when it is actually programmed on the device. Note that the dongle ships with a version of the connectivity firmware installed which includes the DFU Trigger library. So with a new dongle, it will show up in nRF Connect programmer. If you hare programmed it with firmware without the DFU trigger library it will not, and in that case you need to recover by pressing the reset button. If you need the DFU trigger library functionality it is your responsibility to not flash firmware that does not have it.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Mon, 25 Oct 2021 09:09:32 GMT

(I still have not figured out how to make quotes like you have done.)

So if I understand you correctly, even though my app is NOT YET INSTALLED on the dongle, by including the trigger library and all the usb and related stuff around it into my app I will be able to install this app onto the dongle without pressing the reset button - even though the nRF COnnect programmer does not see the dongle. I don't understand how that will work!

That being said, it sounds like it would be easier to copy my app code into examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci

than trying to find and configure SES or Keil with the mssing project files and h files. I had gotten a couple of hours into that and new mssing references just kept coming and trying to find them inthe SDK was a tedious and time consuming task.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Mon, 25 Oct 2021 08:59:56 GMT

Hi,

[quote user="brianreinhold"]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.[/quote]

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.

[quote user="brianreinhold"]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?[/quote]

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

[quote user="brianreinhold"]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.[/quote]

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Mon, 25 Oct 2021 08:47:31 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Mon, 25 Oct 2021 06:30:22 GMT

Hi,

[quote user="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.[/quote]

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

[quote user="brianreinhold"]\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci\[/quote]

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.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Fri, 22 Oct 2021 19:03:54 GMT

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.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Wed, 06 Oct 2021 13:23:11 GMT

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.

[quote user="brianreinhold"]The huge overhead will probably also mean a corresponding cost in power - memory alone.[/quote]

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

[quote user="brianreinhold"]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)?[/quote]

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

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Wed, 06 Oct 2021 13:11:24 GMT

So I take it this information is not documented anywhere. It's figure it out from the example. No wonder so many are having issues.

And as I said above, I use both compilers, Keil and Segger. The huge overhead will probably also mean a corresponding cost in power - memory alone. 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)?

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Wed, 06 Oct 2021 12:46:09 GMT

I understand the problem, but this is the way it is. You will probably not be able to get this to fit within the size limitation of Keil, so you should consider an alternative. Either obtain a Keil silence, or use Segger Embedded Studio, which is also an excellent IDE which you can use free of charge when developing for a nRF device.

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Wed, 06 Oct 2021 12:11:10 GMT

My original project used no USB. Its a BTLE project which advertises as a cycle power and heart rate service. When connected it starts scanning for non connectable advertisements sent by a stationary exercise bike. It decodes the advertisement and notifies the connected client the power, crank, and heart rate data.

The project uses the LEDs, SoftDevice for BTLE and flash writes and not much else besides all the necessary files for the board and other hardware support like the RTC. There are probably files I don't need still in the project but I have no idea what many of them do. I have tried to get rid of all superfluous material but I am sure I am no where close.

The compiled image according to Keil (with logging disabled) is 10K. It's pretty small which is nice.

It does not use any USB.

Building the example project cited above gives 70K according to Keil. That alone is frightening. I have the size limited version of Keil but have been using it since it is better at finding potential problems with its warnings. I have my project in Segger as well when I need intense logging at Debug level with 0 optimization which makes the code image just over the limit for Keil.

As far as porting over the files from the cited project are concerned it would be nice to know from some documentation what files are necessary and where they are and what sdk_config options are necessary and what they are. Finding the source files once you have their names is a task in itself. Every time I added one I would get new undefined references sometime due to missing sdk_config settings and sometimes due to missing c-files or both. The c-files are scattered across several different directories as I soon learned. At least the h-files are easier to find since they are listed in the Keil config and extra h-files do not cost on the final build size or efficiency.

After several hours of adding, searching, rebuilding, and just continuing to get new errors I figured I must be on the wrong track. Probably added files I didn't need which required more unneeded files etc. I was adding files without usbd or trigger in the names.

I am making a desperate call for documentation. From what is out there, it sounded easy as adding a few methods and a reference to a library.

RE: How to use the trigger library to program the nRF52840 dongle

Einar Thorsrud — Wed, 06 Oct 2021 10:37:41 GMT

Hi,

There is not that much to say really, other than that yes, there are a log of dependencies, and if you want to use the USB DFU trigger library you need to add them all. If your project use USB allready they will probably not add too much. If it does not, then there is quite a bit.

If you refer to the example I suggested, you can use that as a reference. Or you can base what you do on build warnings/error. Looking at the log you posted you can check which files those symbols are defined in, and make sure you add related .c files and include paths. And also remember to enable the relevant parts of sdk_config.h. I suggest you copy large sections of the example sdk_config.h, yes. Not necessarily everything, but for instance if adding USB copy the whole section, and then adapt afterwards if needed. That is much more efficient than picking single configuration defines at a time.

This is a bit of tedious work, but this is how the nRF5 SDK is organized and so it is just how it is when you work with it (the nRF Connect SDK is better in this regard, as such tasks are automated by the build system there).

RE: How to use the trigger library to program the nRF52840 dongle

brianreinhold — Tue, 05 Oct 2021 16:03:01 GMT

This is absurd!! I am adding file after file and every time there are more and more undefined symbols.

I have had to add many config items in the sdk_config.h file and there are only more undefined references.

Catch this!!

.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol app_usbd_nrf_dfu_trigger_class_methods (referred from nrf_dfu_trigger_usb.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrf_drv_power_init (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrf_drv_power_usbevt_init (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrf_drv_power_usbevt_uninit (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_active_irq_config (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_disable (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_enable (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_disable (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_dtoggle_clear (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_enable (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_enable_check (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_handled_transfer (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_stall (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_stall_clear (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_transfer (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_force_bus_wakeup (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_init (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_is_enabled (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_is_initialized (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_start (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_stop (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_suspend (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_suspend_irq_config (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_uninit (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_wakeup_req (referred from app_usbd.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_max_packet_size_get (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_ep_stall_check (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_feeder_buffer_get (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_last_setup_dir_get (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_setup_clear (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_setup_data_clear (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_setup_get (referred from app_usbd_core.o).
.\_build\nrf52840_xxaa.axf: Error: L6218E: Undefined symbol nrfx_usbd_setup_stall (referred from app_usbd_core.o).

By the time this is done my 10K project is going to be 100K. Is this for real? How big is the overhead here? Building that project gives a size of more than 70K. I thought it would be adding two methods and a few source files and two config lines.

I can't even find half of these undefined symbols. They are all over the place in the SDK

Everywhere I see this Macro

NRF_MODULE_ENABLED(...)

The code after it is disabled. More config items copied into the sdk_config.h file and still more undefined references but some of those disables become enabled.

DO I have to copy the entire sdk_config.h file into mine and then include every c-file in the project into mine?