Hi.

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)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

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.

Questions:
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)

Thanks,
Helge

Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards,
Brix
-- 
Henrik Brix Andersen

> On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@...> wrote:
>
> Hi Helge,
>
> 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.
>
> BR
> Erwan
>
>
>
> On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@...> wrote:
> Hi.
>
> 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)
> {
>     ARG_UNUSED(port);
>     stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));
>
>     const struct device *porti = device_get_binding("GPIOI");
>     gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
>     gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);
>
>     return 0;
> }
>
> 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.
>
> Questions:
> 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)
>
> Thanks,
> Helge
>
>