Buttonless DFU service does not start when NRF_LOG_ENABLED is set 0

[AntonHellbe]

Hi all,

I have a very strange problem with the Buttonless DFU service. For my project we have two different builds, one debug and one "release" build. The debug build sets the following SDK config defines to 1, and the release build sets them to 0.

• NRF_SDH_BLE_LOG_ENABLED
• NRF_SDH_SOC_LOG_ENABLED
• NRF_SDH_LOG_ENABLED
• NRF_LOG_BACKEND_RTT_ENABLED
• NRF_LOG_ENABLED

When I compile the project and flash the debug build (application + softdevice + bootloader) the application starts up and I can access the DFU service. However when I compile and flash the "release" build the application does not start. If I remove the DFU service the application starts up with both builds, so there's something happening when I disable the logs with the DFU service. Its very hard to debug since everything works the logs are enabled.

I've had some issues before with observers being optimized way since the source code from the libs is not being directly referenced from my code. Could it be something similar going on here? https://devzone.nordicsemi.com/support/224969 (Private ticket)

All help is appreciated, this is a very annoying problem!

[Vidar Berg]

Hi,

Maybe I'm way off but I wonder if it could be caused by an invalid CRC value in your bl settings page which would cause the bootloader to enter DFU mode. Is this page being re-generated each time you compile the app? As you may know, the settings page includes a CRC checksum value of the app image which must match the CRC of the actual app image stored in flash. The bootloader will not "jump" to the application if there's a mismatch. Does your device appear to be stuck in DFU mode? 

[AntonHellbe]

Hi Vidar,

Yes everytime we flash we re-generate the settings page.

I know that the bootloader starts the application because we have different "modes" in the application, 2 of them does not use the DFU service. When I put the nRF52832 in one of the two other modes that does not use the DFU service I can see the advertisement and I can connect.

/ Anton

[Hadi Deknache]

We are currently using SDK version 15.0. I have noticed that when we hard code the Enable_logging=0 flag in the sdk_config.h file, the application works fine, however, the application get stuck in log_skip() when changing the flag in the makefile. 

[Vidar Berg]

Could it possible that Enable_logging gets redefined in your code? log_skip() will not be built if  NRF_LOG_ENABLED==0

[Hadi Deknache]

Enable_logging shouldn't be redefined elsewhere since it is only defined in sdk_config.h and the makefile when compiling it as release. This is how the application is written currently:

/*******Makefile******/

build_release: _app
	ENABLE_LOGGING=0 BUILD_TYPE=app TARGET=nrf52 ...
	
ifeq ($(ENABLE_LOGGING),)
$(info ENABLE_LOGGING not defined, using default ENABLE_LOGGING=1.)
else
$(info ENABLE_LOGGING=$(ENABLE_LOGGING))
CFLAGS += -DENABLE_LOGGING=$(ENABLE_LOGGING)
endif

/******Makefile*******/

/******sdk_config.h*******/

#ifndef ENABLE_LOGGING
#define ENABLE_LOGGING 1
#endif

/*****sdk_config.h*******/

Also, I have noticed that if we do not init dfu service, then the application works perfectly. Shouldn't the application crash elsewhere in the code if that was the case?

[Vidar Berg]

Is NRF_LOG_ENABLED defined somewhere, or have you renamed it to ENABLE_LOGGING?  

Hadi Deknache said:

Also, I have noticed that if we do not init dfu service, then the application works perfectly. Shouldn't the application crash elsewhere in the code if that was the case?

I agree, and I'm not sure I can't explain why. I have tried to replicate the problem here by enabling logging while having all backends disabled, etc but with no luck so far. 

[Hadi Deknache]

NRF_LOG_ENABLED is defined below as following:

#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED ENABLE_LOGGING
#endif

We have only changed the defined value with the defined variable ENABLE_LOGGING

[Vidar Berg]

Looking at the old case linked to in the OP I see you are building a "sdk" library of common files first. Is it rebuilt with the same flags? It seems clear that this has something to do with the build system at least.