defconfig takes precedent over prj_release.conf

[underpickled]

I am using an NRF52DK with NCS 2.5.1.

I was struggling to measure system shutoff power, noting that even the systemoff examples were giving static currents around 200uA.

I eventually found that CONFIG_SERIAL was being set to 'y', even though it was set to 'n' in my prj_release.conf, because it was set to 'y' in nrf52dk_nrf52832_defconfig. Setting CONFIG_SERIAL=n in nrf52dk_nrf52832_defconfig gave me the power numbers I was expecting, but my understanding was that the defconfig file was supposed to set some baseline default settings and that the prj_release.conf file should take precedent. I'm reluctant to rely on changing that defconfig because it's part of the SDK and my customizations should live in my codebase. Is this how it's supposed to work, or is there some way to make my config file take precedent?

I should note that VSCode says that CONFIG_SERIAL is set to n, but it clearly is getting built into the app as evidenced by the current consumption.

Thank you!

[Vidar Berg]

Hello, 

~200 uA is the typical leakage current if you have a floating input (GPIO states are retained in System OFF). 

my understanding was that the defconfig file was supposed to set some baseline default settings and that the prj_release.conf file should take precedent.

Your understanding is correct, and I'm not sure why this happened in your build. The default settings from the board file should not take precedence over the Kconfig settings applied by the application.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.1/zephyr/build/kconfig/setting.html#the-initial-configuration 

Could you please check the .config output in build/zephyr to verify if the other configurations from prj_release.conf were applied successfully? Is it possible that prj_release.conf was not being used?

Best regards,

Vidar

[underpickled]

Vidar Berg said:

~200 uA is the typical leakage current if you have a floating input (GPIO states are retained in System OFF). 

I did see this mentioned in another ticket, but I'm not using any GPIO in my code (other than ADC and NFC functionality). I still tried disabling GPIO altogether in the .conf file and marking all the GPIO/SPI/I2C disabled in my devicetree overlay. I even flashed the NFC-system-off sample project and found the same behavior. The current only went away when I disabled serial in the defconfig. I actually did check the build/zephyr/.config file and found that serial did not seem to be enabled there, which was also very strange.

[Vidar Berg]

underpickled said:

I did see this mentioned in another ticket, but I'm not using any GPIO in my code (other than ADC and NFC functionality).

This applies to GPIOs assigned to peripherals as well, such as the UART RX pin in this case (it is configured as an input by the serial driver). 

underpickled said:

I still tried disabling GPIO altogether in the .conf file and marking all the GPIO/SPI/I2C disabled in my devicetree overlay. I even flashed the NFC-system-off sample project and found the same behavior. The current only went away when I disabled serial in the defconfig.

This is strange. It is not something I have encountered before. 

Vidar Berg said:

Could you please check the .config output in build/zephyr to verify if the other configurations from prj_release.conf were applied successfully? Is it possible that prj_release.conf was not being used?

Alternatively, you could try adding 'CONFIG_SERIAL=n' to the prj.conf file to see if that makes any difference. 

[underpickled]

Vidar Berg said:

This applies to GPIOs assigned to peripherals as well, such as the UART RX pin in this case (it is configured as an input by the serial driver). 

Do I still need to disable that GPIO specifically if I have 'CONFIG_SERIAL=n' set?

Vidar Berg said:

Alternatively, you could try adding 'CONFIG_SERIAL=n' to the prj.conf file to see if that makes any difference. 

Sorry if this wasn't clear in the original post, but I did have that set in prj.conf, but it wasn't until I set it to that in the defconfig also that the current went away. Depending on your answer to the bit about the UART GPIO, maybe that could be what's going on, but it's very strange that the settings in prj.conf don't handle it.

[Vidar Berg]

underpickled said:

Do I still need to disable that GPIO specifically if I have 'CONFIG_SERIAL=n' set?

No, following a reset, all GPIOs are configured as inputs with the input buffer disconnected, meaning that the pin must be re-configured as an input with the input buffer connected by a driver or similar for leakage to become an issue. So, I think we need to figure out why the default 'CONFIG_SERIAL' setting from 'nrf52dk_nrf52832_defconfig' is being applied instead of the configuration specified in your 'prj.conf/prj_release.conf' file.

underpickled said:

Sorry if this wasn't clear in the original post, but I did have that set in prj.conf, but it wasn't until I set it to that in the defconfig also that the current went away. Depending on your answer to the bit about the UART GPIO, maybe that could be what's going on, but it's very strange that the settings in prj.conf don't handle it.

Thank you for the clarification. I understood that you needed to change the default value in defconfig to disable 'CONFIG_SERIAL.' However, I assumed that you had two Kconfig fragments in your project source directory: 'prj.conf' and 'prj_release.conf.' And my initial suspicion was that perhaps you added 'CONFIG_SERIAL=n' to the latter, but that this configuration file was not the one actually used in your build. This is why I was asking earlier if you could verify whether the other settings in 'prj_release.conf' was being applied or not.

Below are some screenshots showing how I would disable 'CONFIG_SERIAL' in a fresh project. Please let me know if you notice any differences in our approaches.

Note: The extension may warn you that 'CONFIG_SERIAL' is already set to 'y' in defconfig. However, the symbol value from 'prj.conf' should take precedence, as confirmed by my .config output above.

[underpickled]

I think what I didn't realize is that you need both prj.conf in addition to prj_[buildtype].conf. Thanks for clearing that up!

[Vidar Berg]

This depends on how the project is set up. I assume the prj_[buildtype].conf files only contain debug-related Kconfig settings in your case. That would explain why you need to merge the configuration with prj.conf. Normally, when you use 'Release' and 'Debug' build configurations, you should have one prj_debug.conf file that defines all the symbols needed for the debug build, and another prj_release.conf to build the release build. 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/configuring_app/advanced_building.html#configuring-build-types