GPIO fails to respond to input following flags update

[kseegmiller]

I want to dynamically update several nrf5340dk GPIO active level settings. However as soon as I write the new 'flags' setting using gpio_pin_configure() or gpio_pin_configure_dt(), the GPIO stops responding to input changes. In the device tree the GPIO is configured as follows:

        gpio1_sw: gpio1_sw {

            gpios = < &gpio1 0xa 0x0 >;

            label = "GPIO 1 switch input";

        };

When the device first comes up it will respond correctly to switch input changes but, as soon as I update the 'flags' settings, even if the update changes nothing, the GPIO fails to respond to input changes. Are there other actions I need to take when updating GPIO's on the fly other than just updating the flags?

In addition, attempts to read the GPIO 'flags' settings by calling gpio_pin_get_config() or gpio_pin_get_dt() fail. In my prj.conf I have added CONFIG_GPIO_GET_CONFIG=y, is there something else I need to add to get this to work?

Thanks,

Kyle

[kseegmiller]

Another data point that looks like it might be relevant. On our project we have CAF enabled and it looks like it changes GPIO settings then restores them to the device tree settings, is that correct? If this is the case, is it even possible to expect real time GPIO settings to persist? Is there a way around this?

[AHaug]

Hi,

Could you supply me a minimal sample that showcases what you're doing so I can attempt to recreate the issue and get a better understanding of where the issue may lie?

My guess was that it should be possible to change the GPIOs during run time/dynamically, but it could be that there is a register somewhere that overrides the changes you make through gpio_pin_configure..() 

kseegmiller said:

On our project we have CAF enabled and it looks like it changes GPIO settings then restores them to the device tree settings, is that correct? If this is the case, is it even possible to expect real time GPIO settings to persist? Is there a way around this?

Do you see the same thing when you don't have CAF enabled as well? For instance with a simpler DK button and LED sample?

Kind regards,
Andreas

[kseegmiller]

Andreas,

Thank you for your response and suggestions, Unfortunately I'm not able to dig into this further at this time as we have opted to invert the GPIO output, as needed, rather than change the input active level state.   

Best regards,

Kyle

[AHaug]

Noted, thank you for the update. 

Could you verify if this means we can close this issue for now? You can always either reopen it later or create a new ticket and refer to this one at a later point in time

Kind regards,
Andreas

[kseegmiller]

Yes, go ahead and close it,

Thanks again,

Kyle