Buttonless DFU Debugging Problem

RE: Buttonless DFU Debugging Problem

Vidar Berg — Mon, 20 Aug 2018 12:02:00 GMT

Jeff,

Happy to help:) Yes, you need to enable pull-up on the pin, see BUTTON_PULL define in you BOARD header.

Update: guess I responded too quickly. Based on the schematic, I don't think it make sense that it works when you hold the button on power-up.

Here are the lines of code that determines if the bootloader should enter DFU mode (nrf_bootloader.c::dfu_enter_check):

static bool dfu_enter_check(void)
{
if (!nrf_dfu_app_is_valid(crc_on_valid_app_required()))
{
NRF_LOG_DEBUG("DFU mode because app is not valid.");
return true;
}

if (NRF_BL_DFU_ENTER_METHOD_BUTTON &&
(nrf_gpio_pin_read(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN) == 0)) // Active low
{
NRF_LOG_DEBUG("DFU mode requested via button.");
return true;
}

if (NRF_BL_DFU_ENTER_METHOD_PINRESET &&
(NRF_POWER->RESETREAS & POWER_RESETREAS_RESETPIN_Msk))
{
NRF_LOG_DEBUG("DFU mode requested via pin-reset.");
return true;
}

if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
(nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
{
NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
return true;
}

if (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS &&
(s_dfu_settings.enter_buttonless_dfu == 1))
{
NRF_LOG_DEBUG("DFU mode requested via bootloader settings.");
return true;
}

return false;
}

And the bootloader button initialization (nrf_bootloader.c::dfu_enter_button_init):

nrf_gpio_cfg_sense_input(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN,
BUTTON_PULL,
NRF_GPIO_PIN_SENSE_LOW);

RE: Buttonless DFU Debugging Problem

JeffW — Mon, 20 Aug 2018 11:59:34 GMT

Vidar,

Holding down the button on power-up fixed the issue.
This is strange to me, as the button is pulled low on contact. (See schematic)
Perhaps I need to activate an internal pull-up inside the boot?

Thanks for your continued support!
Jeff

RE: Buttonless DFU Debugging Problem

Vidar Berg — Mon, 20 Aug 2018 11:44:57 GMT

Jeff,

thanks for confirming. Maybe it could be the bootloader button pin then. The bootloader will enter DFU mode if the NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN is pulled low on startup?

Vidar

RE: Buttonless DFU Debugging Problem

JeffW — Mon, 20 Aug 2018 11:37:07 GMT

Vidar,

This was a good thought, however my custom board has an LF crystal.
I did try to run it using the internal RC as suggested with no favorable results. (Stays in Boot)

I will be continuing debugging this issue over the next couple of days. If you can think of any other reasons this would happen, please let me know.

Thanks,
Jeff

RE: Buttonless DFU Debugging Problem

Vidar Berg — Mon, 20 Aug 2018 08:36:17 GMT

Does your custom board have an external LF crystal? Reason I ask is that all SDK bluetooth examples are configured to use the optional LF crystal. If not you need to enable the internal RC oscillator in sdk_config.h (both app and bootloader project):

......

//==========================================================

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
 
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

RE: Buttonless DFU Debugging Problem

JeffW — Fri, 17 Aug 2018 12:22:02 GMT

I now am able to program + debug the boot for the buttonless dfu, and modified template app on the development kit. However now I am getting the same or similar issue when I flash one of those working examples to my custom board.

I modified the boot to not turn the DK LED pins and boot button because of my CUSTOM_BOARD macro, but perhaps I am missing another step. The program again loads right into the boot even though the example is working on the DK.

Any insight would be appreciated.

RE: Buttonless DFU Debugging Problem

JeffW — Wed, 15 Aug 2018 19:32:03 GMT

Thanks Vidar for the prompt response!
I got this working this afternoon after changing to my output macros.

RE: Buttonless DFU Debugging Problem

Vidar Berg — Wed, 15 Aug 2018 14:34:48 GMT

Hi Jeff,

I encountered the same problem here. That is, checksum of app image did not match with the one stored in the generated bl settings page and therefore became stuck in DFU mode. Further debugging revealed that the there was a slight difference if I uploaded the .hex file instead of the .elf file in the build directory:

Not sure if this is expected behavior or if it is a bug in binutils (tested with SES v.3.50). In any case, I worked around this be changing the debugger settings in SES to upload the .hex file instead. Screenshots of my configuration:

(Post build command : nrfutil settings generate --family NRF52840 --application $(OutDir)/$(ProjectName).hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 $(OutDir)/settings.hex)