- v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization
Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization
toggle quoted messageShow quoted text
Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.
Anyway, the problem still stands.
I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.
I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.
I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:
static int pinmux_stm32_init(const struct device *port)
const struct device *porti = device_get_binding("GPIOI");
gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);
This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.
During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.
1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)
Join firstname.lastname@example.org to automatically receive all group messages.