Can't remap stm32 qdec to TIM3 AF2

[digiexchris]

Hello, I'm trying to get the qdec sample working on an STM32F411CEU6, which is pin compatible for TIM3 a6/a7/b0/b1 and the DTS shown in the sample readme. I confirmed that the sample works correctly with the DTS provided, but I need to use PB0 and PB1 because I need PA7 for SPI1. I've attempted to remap it with the following overlay, but I get no encoder output with the QDEC sample. I first tried without the addition of the pinctrl/pinmux nodes, which leaves the only difference from the sample is pinctrl-0 = <&tim3_ch3_pb0 &tim3_ch4_pb1>;

Am I doing something wrong? The pullups and the hardware is identical to how it was working on &tim3_ch1_pa6 &tim3_ch2_pa7.

I checked this on 3 different boards to make sure it's not hardware.

/ {
aliases {
qdec0 = &qdec;
};
};

&timers3 {
status = "okay";

qdec: qdec {
    status = "okay";
    pinctrl-0 = <&tim3_ch3_pb0 &tim3_ch4_pb1>;
    pinctrl-names = "default";
    st,input-polarity-inverted;
    st,input-filter-level = <FDIV32_N8>;
    st,counts-per-revolution = <16>;
};

};

&pinctrl {
tim3_ch3_pb0: tim3_ch3_pb0 {
pinmux = <STM32_PINMUX('B', 0, AF2)>;
bias-pull-down;
};

tim3_ch4_pb1: tim3_ch4_pb1 {
    pinmux = <STM32_PINMUX('B', 1, AF2)>;
    bias-pull-down;
};

};

[ndrs-pst]

@digiexchris After I looked at int qdec_stm32_initialize(const struct device *dev) in qdec_stm32.c, it seems that the driver is fixed to use CH1 and CH2.
This may be a constraint of the TIM itself, then please see LL_TIM_ENCODER_StructInit.

[digiexchris]

thank you for looking into this! I see that you're correct, it's forcibly configuring TC1 and TC2. Do you know why this would be fixed to those channels? I have an example in stm32cubemx without zephyr where this is working on every stm32f1 and f4 board I have. Should I open an issue about it? Without this I may not be able to port some hardware to zephyr and take advantage of the abstractions I find useful in zephyr.

[ndrs-pst]

According to ST's reference manual, I think this is a hardware constraint. Could you please clarify which example in stm32cubemx you are referring to?

---

[digiexchris]

Ah yes I see, the datasheet was unclear about this, it seemed to say that the alternate functions were flexible, but I suppose we can only assume that certain functions can only use ch1 and 2. I was wrong about the examples I had found also, they were doing software decoding using GPIO interrupts instead of using the hardware encoder mode.

Why does Zephyr not return an error if someone is trying to enable encoder mode with an invalid channel selected? It silently accepted it and did nothing.

[ndrs-pst]

It's indeed challenging for Zephyr to cover such cases, particularly with the wide variety of hardware configurations it supports.
To mitigate this, I recommend using STM32CubeMX as a complementary tool. It can help verify hardware compatibility before implementing your setup in Zephyr. 🚀

[digiexchris]

I agree that it can be challenging, but in this case i believe it's just simple defensive programming that might have been overlooked by accident. When code is hard coding something, it shouldn't accept parameters that conflict with that. We don't even need to determine if the hardware supports the other configuration, because the written driver doesn't support it. The stm32-pwm driver does this well, it throws ENOTSUP if you attempt to pass a 32 bit period to a 16 bit timer. Which is what I expected with a framework that is safety certified and advertising hardware abstraction.

Maybe when I have some time I'll make a PR. I can just check if the passed in device is setup for !TIM1 && !TIM2. For now I'll consider this closed, it was my problem all along :D