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

  • 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

  • Let me confirm if my understanding is correct.

    In DK hardware, the GPIO P0.21 is routed out to the external flash chip for QSPI, so configuring p0.21 as input in software will cause an assertion to occur because nRF SDK detected conflict.

    If I want to avoid assertion, I need to make hardware modifications and disconnect the connection between p0.21 and the external flash chip. 

    So far, am I right?

    But if you have a custom board, or a different board where this pin is routed out, you should be able to use it. 

    I've started thinking that maybe the board I am using is not entirely a custom board. Let me confirm the definition of a custom board. A custom board refers to a board where the chip (e.g., nrf52840) used is the original, unmodified chip from the factory, not processed or altered by anyone else, is that correct?

    The MDBT50Q-1MV2, because it already integrates the Bluetooth antenna onto the nrf52840, is considered a type of custom board. Since I am using it as the IC for my board, my board is not entirely a custom board because the IC part was not designed by me.

    Although on my board the P0.21 is as input routed out to the charger IC. But I don't know if P0.21 has routing to the external flash memory chip before I use it. because the MDBT50Q-1MV2 was not designed by me.

    Is the external flash memory  can packaging with IC together?

    If external flash memory can packaging with IC. Maybe that is why I used CONFIG_ASSERT=y the assertion always happen, because the P0.21 on the MDBT50Q-1MV2 still routed out to the external flash chip.

    Do you see that it works as expected now?

    On no CONFIG_ASSERT=y case, the p0.21 can successful read high/low value as input. If the above assumptions are true, then perhaps only not use CONFIG_ASSERT=y is the only way.

    Best regards,

    Teson

Reply
  • Let me confirm if my understanding is correct.

    In DK hardware, the GPIO P0.21 is routed out to the external flash chip for QSPI, so configuring p0.21 as input in software will cause an assertion to occur because nRF SDK detected conflict.

    If I want to avoid assertion, I need to make hardware modifications and disconnect the connection between p0.21 and the external flash chip. 

    So far, am I right?

    But if you have a custom board, or a different board where this pin is routed out, you should be able to use it. 

    I've started thinking that maybe the board I am using is not entirely a custom board. Let me confirm the definition of a custom board. A custom board refers to a board where the chip (e.g., nrf52840) used is the original, unmodified chip from the factory, not processed or altered by anyone else, is that correct?

    The MDBT50Q-1MV2, because it already integrates the Bluetooth antenna onto the nrf52840, is considered a type of custom board. Since I am using it as the IC for my board, my board is not entirely a custom board because the IC part was not designed by me.

    Although on my board the P0.21 is as input routed out to the charger IC. But I don't know if P0.21 has routing to the external flash memory chip before I use it. because the MDBT50Q-1MV2 was not designed by me.

    Is the external flash memory  can packaging with IC together?

    If external flash memory can packaging with IC. Maybe that is why I used CONFIG_ASSERT=y the assertion always happen, because the P0.21 on the MDBT50Q-1MV2 still routed out to the external flash chip.

    Do you see that it works as expected now?

    On no CONFIG_ASSERT=y case, the p0.21 can successful read high/low value as input. If the above assumptions are true, then perhaps only not use CONFIG_ASSERT=y is the only way.

    Best regards,

    Teson

Children
  • Can you confirm that you are not able to detect the interrupts on the P0.21?

    SmallWood said:
    If I want to avoid assertion, I need to make hardware modifications and disconnect the connection between p0.21 and the external flash chip. 

    You are using a custom board, right? If so, then you don't need to make any changes. 

    If it doesn't work, you can try adding this to your .overlay file:

    /delete-node/ &mx25r64;

    SmallWood said:
    A custom board refers to a board where the chip (e.g., nrf52840) used is the original, unmodified chip from the factory, not processed or altered by anyone else, is that correct?

    I would say that if you are not using a DK, at least to me, that is a custom board. The board refers to the PCB that the chip is mounted on. 

    The module that you link to is probably mounted on a PCB that is not produced by Nordic (because we don't produce any PCBs with that module). So on your board, you probably don't have an mx25r64 (external flash chip) connected to the P0.21. So in that manner, yes, you have a custom board.

    But if you are building for the nrf52840dk_nrf52840, then the chip thinks it sits on a standard DK, and it believes that the buttons and LEDs are on the same place as they use to be on the DK, which may not be the case. However, in that case, I should see the same warnings/errors as you see when running it on an actual nRF52840DK. 

    Try adding this to your .overlay file:

    /delete-node/ &mx25r64;
    

    And if that doesn't help, can you please take a picture of the device you are working on and upload it here?

    Best regards,

    Edvin

  • Can you confirm that you are not able to detect the interrupts on the P0.21?

    I can detect the interrupts on the P0.21 when I comments the CONFIG_ASSERT=y.

    You are using a custom board, right? If so, then you don't need to make any changes. 

    Right. I see.

    So in that manner, yes, you have a custom board.

    Thank you. I understand.

    Try adding this to your .overlay file:

    I added, and when I build. There is an error happened.

    devicetree error: /aliases: undefined node label 'mx25r64'

    Here is my .overlay

    / {
    	zephyr,user {
    		chrg_state-gpios = <&gpio0 21 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>; // 27 work, 21 assertion
    	};
    };
    
    /delete-node/ &mx25r64;
    /delete-node/ &i2c0;

    And I try disabled qspi, but still error.

    &qspi {
    	status = "disabled";
    };
    

    And if that doesn't help, can you please take a picture of the device you are working on and upload it here?

    Sure. The following is the board I use.

    This is my code. I delete the PM. Now there is only P0.21 interrupt. I cance the comments of CONFIG_ASSERT=y in prj.conf.

    4657.button.zip

    By the way, I misunderstood the meaning of 'annotations' and 'comments'. 

    Sorry to trouble you all the time. 

    Best regards,

    Teson

  • Hello,

    So you have the Raytac equivalent of our DK. In that case, I suggest you try to build for that board, instead of our board. That means, create a new build configuration, and build for the board raytac_mdbt50q_db_40_nrf52840, and replace your nrf52840dk_nrf52840.overlay with raytac_mdbt50q_db_40_nrf52840.overlay, and remove the reference to mx25r64 (I also couldn't build, but I didn't dig into why it didn't work, since it is not present on your board). 

    Best regards,

    Edvin

  • Thank you very much. I finally can use the p0.21 as input without ASSERT when CONFIG_ASSERT=y.

    Best regards,

    Teson

  • Glad to hear that it worked!

    I'll close this ticket now. Open it if you have any related issues, or open a new ticket if you encounter any new issues. 

    Best of luck!

    Best regards,

    Edvin

Related