How to use the trigger library to program the nRF52840 dongle

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?

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

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

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

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

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

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

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

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

  • Hi,

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

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

    brianreinhold said:
    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!

    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.

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

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

  • 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

Related