Gpio config input cause assertion & config missing dependencies

I use SDK v.2.6.1. To avoid other possible factors affecting the results, I only keep the simplest function in the code which is reading the potential of gpio every second and using log to display it on RTT. I have two questions and would like to ask. Thank you.

1. When setting p0.21 of gpio as input, the program will have an assertion error(as the follow fig). I have canceled qspi and i2c0 in the file .overlay.

At first I thought it was a bug in my program, so I modify the sample code zephyr/samples/basic/button and run it. But I soon discovered that this was not a problem with the code, because in the same code, when I set p0.27 as input rather than p0.21, the code could run normally(as the follow fig). I didn’t understand why! I knew that the comment CONFIG_ASSERT=y could Let the program run successfully, but this is not the result I want. How to make p0.21 an input pin?

2. In prj.conf, some configs will have missing dependencies. Will missing dependencies cause config settings fail?
(e.g. CONFIG_UART_CONSOLE was assigned the value y, but got the value n. Missing dependencies: SERIAL && SERIAL_HAS_DRIVER). If the setting fails, how to modify it to make the setting successful?

My prj.conf is as follows

CONFIG_GPIO=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_ASSERT=y
CONFIG_LOG=y

My .overlay is as follows

/ {
	zephyr,user {
		chrg_state-gpios = <&gpio0 21 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
	};
};

/delete-node/ &i2c0;

&qspi_default {
	group1 {
		psels = <NRF_PSEL(QSPI_SCK, 0, 19)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>,
				<NRF_PSEL(QSPI_CSN, 0, 17)>;
	};
};

&qspi_sleep {
	group1 {
		psels = <NRF_PSEL(QSPI_SCK, 0, 19)>,
				<NRF_PSEL(QSPI_IO0, 0, 20)>,
				<NRF_PSEL(QSPI_IO2, 0, 22)>,
				<NRF_PSEL(QSPI_IO3, 0, 23)>;
	};
};

My main program is as follows

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/logging/log.h> 
LOG_MODULE_REGISTER(Custom_Board,LOG_LEVEL_DBG);

static int ret, bat_chrg_state;

#define SLEEP_TIME_MS   1000
#define zephyr_user_NODE DT_PATH(zephyr_user)
static const struct gpio_dt_spec chrg_state = GPIO_DT_SPEC_GET(zephyr_user_NODE, chrg_state_gpios); // chrg_state節點

int main(void)
{

	if (!gpio_is_ready_dt(&chrg_state)) {
		LOG_ERR("chrg_state is not ready");
		return 0;
	}

	ret = gpio_pin_configure_dt(&chrg_state, GPIO_INPUT);
	if (ret != 0) {
		LOG_ERR("Error %d: failed to configure %s pin %d\n",
			ret, chrg_state.port->name, chrg_state.pin);
		return 0;
	}

	for(;;){
		bat_chrg_state = gpio_pin_get_dt(&chrg_state);
		LOG_INF("bat_chrg_state:%d",bat_chrg_state);
		k_msleep(SLEEP_TIME_MS);
	}
}

Parents
  • Hello,

    1. When setting p0.21 of gpio as input, the program will have an assertion error(as the follow fig). I have canceled qspi and i2c0 in the file .overlay.

    I am not quite sure about this one. Is it possible to upload the application that reproduces this error on a DK?

    2. In prj.conf, some configs will have missing dependencies. Will missing dependencies cause config settings fail?
    (e.g. CONFIG_UART_CONSOLE was assigned the value y, but got the value n. Missing dependencies: SERIAL && SERIAL_HAS_DRIVER). If the setting fails, how to modify it to make the setting successful?

    Yes and no. It depends on where you see these warnings.

    When you see a squiggly line when modifying your prj.conf (or any other .conf file) those can be pointers to something that is wrong. But it may also be the parser in VS code being confused. However, when building, if you see the same message in the build log, it means that the config was not set correctly, because of a missing dependency. In this case, try adding CONFIG_SERIAL=y before CONFIG_UART_CONSOLE=y.

    Best regards,

    Edvin

  • Hello, 

    1. I used the the MDBT50Q-DB-40, which I don't sure is it also DK? The application is produces this error on this "DK". Beside,I already made some custom PCB which also used nRF52840. Because I found this error on CB first, so I tried to reproduce this error on DK to check was my CB design wrong? And the DK did reproduce the error. So I thought the problem isn't the CB. It should something I don't know to cause this problem.

    2. In my main project, I have lots of missing dependency messages in my prj.conf. But when I build, I only saw "warning: PM" as the follow. Is that mean all of the config set except PM config assigned successful?

    warning: PM (defined at soc/arm/silabs_exx32\efr32bg22\Kconfig.defconfig.series:18,
    soc/arm/silabs_exx32\efr32bg27\Kconfig.defconfig.series:18,
    soc/arm/silabs_exx32\efr32mg24\Kconfig.defconfig.series:19,
    soc/arm/st_stm32\stm32f4\Kconfig.defconfig.series:20, subsys/pm/Kconfig:13) was assigned the value
    'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
    SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32BG27 && SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32MG24 &&
    SOC_FAMILY_EXX32) || SOC_SERIES_STM32F4X || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See
    http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_PM and/or look up PM in the
    menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
    and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

    About my PM config is as follow, I noted the CONFIG_PM=y is dependencies on CONFIG_SYS_CLOCK_EXISTS &&CONFIG_HAS_PM and CONFIG_POWEROFF=y is dependencies on CONFIG_HAS_POWEROFF.

    But except the CONFIG_SYS_CLOCK_EXISTS, the other 2 config not directly user assignable. How should I let CONFIG_PN & CONFIG_POWEROFF set successful?

    # ============================================================================= #
    #           PM                                                                  #
    # ============================================================================= #
    CONFIG_SYS_CLOCK_EXISTS=y
    CONFIG_PM=y
    CONFIG_PM_DEVICE=y
    CONFIG_PM_DEVICE_RUNTIME=y
    CONFIG_CRC=y
    CONFIG_POWEROFF=y

    Best regards,

    Teson

  • The fact that the build log tries to set a Kconfig in a Silabs board is probably not a good sign. And as you can see, it fails to set it, because of the unsatisfied dependencies (which will obviously fail, because it is not a Silabs device. 

    What board are you building for? Did you get these errors since the beginning?

    soc/arm/st_stm32\stm32f4\Kconfig.defconfig.series:20, subsys/pm/Kconfig:13) was assigned the value
    'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
    SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32BG27 && SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32MG24 &&
    SOC_FAMILY_EXX32) || SOC_SERIES_STM32F4X || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See

    Is it possible to upload the application that you are trying to build, along with the build command? If you are using VS Code to build, it is possible to copy the build command by right clicking the build configuration and selecting "Copy build command". The copied command is quite long, but I can shrink it down on my side. 

    SmallWood said:
    But except the CONFIG_SYS_CLOCK_EXISTS, the other 2 config not directly user assignable. How should I let CONFIG_PN & CONFIG_POWEROFF set successful?

    I need to have a look at the project. 

    Best regards,

    Edvin

Reply
  • The fact that the build log tries to set a Kconfig in a Silabs board is probably not a good sign. And as you can see, it fails to set it, because of the unsatisfied dependencies (which will obviously fail, because it is not a Silabs device. 

    What board are you building for? Did you get these errors since the beginning?

    soc/arm/st_stm32\stm32f4\Kconfig.defconfig.series:20, subsys/pm/Kconfig:13) was assigned the value
    'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
    SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32BG27 && SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32MG24 &&
    SOC_FAMILY_EXX32) || SOC_SERIES_STM32F4X || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See

    Is it possible to upload the application that you are trying to build, along with the build command? If you are using VS Code to build, it is possible to copy the build command by right clicking the build configuration and selecting "Copy build command". The copied command is quite long, but I can shrink it down on my side. 

    SmallWood said:
    But except the CONFIG_SYS_CLOCK_EXISTS, the other 2 config not directly user assignable. How should I let CONFIG_PN & CONFIG_POWEROFF set successful?

    I need to have a look at the project. 

    Best regards,

    Edvin

Children
  • By chance, I ran into the same issue in another customer sample. You need to use 

    CONFIG_PM_DEVICE=y

    instead of 

    CONFIG_PM=y

    But for the rest of the questions, I need to see the application.

    Best regards,

    Edvin

  • Hello,

    Firstable, I am sorry. Because I am a newbie, so I have many question want to ask.

    The fact that the build log tries to set a Kconfig in a Silabs board is probably not a good sign. And as you can see, it fails to set it, because of the unsatisfied dependencies (which will obviously fail, because it is not a Silabs device. 

    Is the build log means messages which terminal showed when I click "Build"? And what is Silabs board? Is the Silabs board a specific model of board?

    What board are you building for? Did you get these errors since the beginning?

    I build on MDBT50Q-1MV2 which used nRF52840 SoC Solution (Revision 2 IC). No, I didn't see those errors.

    Is it possible to upload the application that you are trying to build, along with the build command?

    Sure! It's the application which I'm test as the follow "button.zip". Since I wanted to solve the assertion problem at the beginning, I did not write the configuration of PM, nor its functions. Now I've added the PM's configuration and written a k_timer to trigger sys_poweroff(). But I don’t know why putting sys_power() in the timer will trigger the assertion, so I annotated k_timer_start() first. Can sys_power() be put into k_timer and work successfully? Or is it prohibited?

    7178.button.zip

    it is possible to copy the build command by right clicking the build configuration and selecting "Copy build command".

    I right clicking the build configuration, but I didn't see the "Copy build command". Did I right clicking the wrong place?

    You need to use 

    CONFIG_PM_DEVICE=y

    instead of 

    CONFIG_PM=y

    I have CONFIG_PM=y and CONFIG_PM_DEVICE=y before. Now I annotated CONFIG_PM=y and I did not receive the dependencies warning at terminal. My program can also run normally and sys_poweroff() also works normally. It seems that there should be no problem. Thank you.

  • SmallWood said:
    Is the build log means messages which terminal showed when I click "Build"?

    Yes. 

    SmallWood said:
    And what is Silabs board? Is the Silabs board a specific model of board?

    I was thinking of these messages from your build log:

    warning: PM (defined at soc/arm/silabs_exx32\efr32bg22\Kconfig.defconfig.series:18,
    soc/arm/silabs_exx32\efr32bg27\Kconfig.defconfig.series:18,
    soc/arm/silabs_exx32\efr32mg24\Kconfig.defconfig.series:19,
    soc/arm/st_stm32\stm32f4\Kconfig.defconfig.series:20, subsys/pm/Kconfig:13) was assigned the value
    'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
    SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32BG27 && SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32MG24 &&
    SOC_FAMILY_EXX32) || SOC_SERIES_STM32F4X || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See

    But as I mentioned, this comes from using CONFIG_PM=y instead of CONFIG_PM_DEVICE=y. So use CONFIG_PM_DEVICE=y. 

    SmallWood said:
    I build on MDBT50Q-1MV2 which used nRF52840 SoC Solution (Revision 2 IC). No, I didn't see those errors.

    When you create your build configuration, you will select a board. What is the board name that you are building for? E.g. if you were using an nRF52840 DK you should use the board name nrf52840dk_nrf52840.

    SmallWood said:
    I right clicking the build configuration, but I didn't see the "Copy build command". Did I right clicking the wrong place?

    This is where I meant you should right click:

    But I can see from your build folder that you were building for the nrf52840dk_nrf52840, which means the nRF52840 DK.

    Yes, testing your sample seems to work (at least while testing on the DK). However, I can't check if the P0.21 works as an input, since it is being controlled by the external flash chip on our DK. It is not routed out to the pin header, without some HW modifications on the DK. 

    Best regards,

    Edvin

  • This is where I meant you should right click

    Oh, I see!

    west build --build-dir c:/Users/User/Desktop/RadiRad/RadiHeart/Tech/Soft/EVMsampleCode/button/build c:/Users/User/Desktop/RadiRad/RadiHeart/Tech/Soft/EVMsampleCode/button --pristine --board nrf52840dk_nrf52840 -- -DNCS_TOOLCHAIN_VERSION="NONE" -DCONF_FILE="prj.conf"

    I can't check if the P0.21 works as an input, since it is being controlled by the external flash chip on our DK.

    May I learn from you. How did you check whether a pin is an output or an input?

    The gpio_pin_get_dt(p0.21) is run and read the correct voltage, so can I guess p0.21 is works as an input?

    It is not routed out to the pin header, without some HW modifications on the DK. 

    Is that because P0.21 is not routed out to the pin header, so the assertion shows the message 'Unsupported pin' ?

    Best regards,

    Teson

  • SmallWood said:
    May I learn from you. How did you check whether a pin is an output or an input?

    I tested your application on P0.27, and there it worked as expected. Then I tested it for P0.21, and it built without any issues, so I assume it works.

    SmallWood said:
    Is that because P0.21 is not routed out to the pin header, so the assertion shows the message 'Unsupported pin' ?

    No. The application is not aware of the external flash on the DK (at least when you set the QSPI pins to something else). 

    So the routing of the P0.21 is something that is only present on the DK. It means that the physical GPIO is not reachable from the pin header. But if you have a custom board, or a different board where this pin is routed out, you should be able to use it. 

    Do you see that it works as expected now?

    Best regards,

    Edvin

Related