DFU programming

RE: DFU programming

Tai — Fri, 08 Mar 2019 21:22:44 GMT

Thanks. It is working perfectly.

RE: DFU programming

Einar Thorsrud — Fri, 08 Mar 2019 14:34:07 GMT

Hi,

DFU is not activated by reset itself, but the bootloader runs after every reset and checks if any of the mechanism uses to signal DFU is enabled. According to your log, the GPIO pin configured to signal that you want to enter DFU mode is asserted. The bootloader will check the GPIO pin defined by NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN in the bootloader projects sdk_config.h if NRF_BL_DFU_ENTER_METHOD_BUTTON is set to 1.

If you don't want to use a GPIO pin to signal DFU mode, set NRF_BL_DFU_ENTER_METHOD_BUTTON to 0. If you just want to use a different pin, set NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN accordingly.

RE: DFU programming

Tai — Fri, 08 Mar 2019 13:11:48 GMT

Hi,

Where can I assign DFU mode button?

Is DFU mode activated by reset?

RE: DFU programming

Einar Thorsrud — Fri, 08 Mar 2019 08:03:29 GMT

Hi,

You can see from the log that the GPIO pin used to enter DFU mode is asserted:

00> <debug> app: DFU mode requested via button.

If you do not use the same button for wakeup as to signal enter DFU mode, then this indicate that you have an issue with your bootloader configuration or perhaps a HW issue with the DFU enter pin (floating?).

If you are pushing the same button as you use to enter DFU mode to wake up the device, then this is expected behavior. You either need to use a different button to force DFU mode (if you have more), use buttonless DFU, or expand the DFU button enter check to for instance require the button to be pushed for a certain duration of time for it to enter the DFU mode (or other alternatives).

RE: DFU programming

Tai — Thu, 07 Mar 2019 22:33:28 GMT

devzone.nordicsemi.com/.../0537.log.txt

Here is the log file:

1- firmware uploaded

2- turn off-on the board to run the application

3- waiting for sleep mode of application:

static void sleep_mode_enter(void)
{
ret_code_t err_code;

err_code = bsp_indication_set(BSP_INDICATE_IDLE);
APP_ERROR_CHECK(err_code);

// Prepare wakeup buttons.
err_code = bsp_btn_ble_sleep_mode_prepare();
APP_ERROR_CHECK(err_code);

// Go to system-off mode (this function will not return; wakeup will cause a reset).
err_code = sd_power_system_off();
APP_ERROR_CHECK(err_code);
}

4- push the button to wake the application up

RE: DFU programming

Einar Thorsrud — Thu, 07 Mar 2019 08:39:11 GMT

Hi,

Can check the bootloader logs? The reason for entering DFU bootloader is logged in dfu_enter_check() in nrf_bootloader.c (assuming SDK 15).

RE: DFU programming

Tai — Thu, 07 Mar 2019 03:12:27 GMT

Hi Elinar,

Thanks agian for your reply.

Now everything is ok. I am using reset and NFC pins as GPIO.

However, I still have an issue. When the program enter to sleep mode, the board backs to DFU mode after waking up. Is there anything I forgot to avoid DFU mode?

RE: DFU programming

Einar Thorsrud — Wed, 06 Mar 2019 13:24:31 GMT

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

RE: DFU programming

Tai — Wed, 06 Mar 2019 13:13:30 GMT

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?

RE: DFU programming

Einar Thorsrud — Wed, 06 Mar 2019 09:41:09 GMT

Hi,

[quote user="tai2020"]- How can I generate log file? I have already compiled pca10040_ble_debug project. How can I generate log file?[/quote]

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.

RE: DFU programming

Tai — Wed, 06 Mar 2019 00:07:23 GMT

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.

RE: DFU programming

Einar Thorsrud — Fri, 01 Mar 2019 13:28:47 GMT

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