This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU programming

Hi everybody,

I am trying to program a custom board via DFU without success. I can build bootloader and zip file. I can even program the file by nRFToolbox on device but it does not work after programming.

Now my questions are:

1- Should I build the bootloader with my custom board or with a standard board files?

2- what about CONFIG_NFCT_PINS_AS_GPIOS? Where should I define them? In bootloader and application options?

  • Hi,

    I have a few questions:

    • Does the DFU operation complete successfully when you do it from nRFToolbox?
    • In what was do you see that it does not work after programming? Does the device stay in DFU mode, or in some other state?
    • Can you try the debug bootloader with RTT logging, and upload the logs here? That should give a good indication about what is happening.

    Regarding your specific questions:

    1. If the board file reflects the parts your HW that is used by the bootloader correctly (LEDs and buttons), then there is no need to change. If not, then you should use a custom board file (or adapt the board file you are using, though it is somewhat dirty).

    2. Having CONFIG_NFCT_PINS_AS_GPIOS set causes the firmware to set the correct UICR register to indicate that the NFC pins should act as normal GPIOs. That only has to happen once (it is essentially a write to flash, you can see the implementation in system_nrf52.c). Therefor it does not matter unless you use one of the NFC pins for something in the bootloader (which runs first).

  • Thanks for reply. Here-below the my answers:

    - Yes. I receive the massage : DFU Upload compelete.

    - It is still staying in DFU mode. I can repeat Firmware Update via nRF toolbox.

    - How can I generate log file? I have already compiled pca10040_ble_debug project. How can I generate log file?

    I used my own cus_board.c and cus_board.h based on defult board.c and board.h. I modified LED and buttom numbers and pins. The custom boards has only 1 buttom connected to reset pin. I could not have used reset pin as GPIO yet.

    I am using nRFgo Studio to program softdevice and keil to develop and program the application. Everything is working without DFU.

  • Hi,

    Tai said:
    - How can I generate log file? I have already compiled pca10040_ble_debug project. How can I generate log file?

    The _debug bootloader projects use RTT logging, so you can obtain the log by connecting a Segger debugger and using RTT Viewer.

    The log should tell us what is happening in the bootloader. Generally, the bootloader will check if it should enter DFU mode, for instance if the GPIO pin used to signal DFU mode is asserted or if the retention register indicates that it should enter DFU mode. If not, it will check if the application is present and valid. If it is, it i will start it. If not, it will enter DFU mode.

  • Hi Elinar,

    It is working now :) I had a problem with reset. When I reset the board, the board goes back to DFU mode. I remove CONFIG_GPIO_AS_PINRESET  from bootloader but the reset pin is still reset.

    My question is, when UICR register is set? During programming bootloader, softdevice or application? How can I make reset as a GPIO pin?

  • Hi,

    The UICR PSELRESET registers will be configured to set GPIO as pin reset when CONFIG_GPIO_AS_PINRESET has been used to build part of your firmware (being bootloader or application). So you must make sure that it is no longer used in either of them. Then you need to erase the UICR to reset it back to the default state, which you do by a full chip erase (most easily by calling "nrfjprog -e").

Related