mcp251xfd strange interrupt configuration

[adri1mart1]

Hello zephyr community,

I'm playing with the mcp251863-click board and with an EFR32MG24.
I'm using the can_mcp251xfd driver and one thing really bother me out.

In the init function, the interrupt is configured using GPIO_INT_LEVEL_ACTIVE:

if (gpio_pin_interrupt_configure_dt(&dev_cfg->int_gpio_dt, GPIO_INT_LEVEL_ACTIVE) < 0) {
	return -EINVAL;
}

However, on the EFR32, the gpios cannot be configured using level interrupts, see gpio driver:

/* Interrupt on static level is not supported by the hardware */
if (mode == GPIO_INT_MODE_LEVEL) {
	return -ENOTSUP;
}

By curiosity, I've checked on stm32 and it seems it does not support it as well: --> see driver

My question is:

• Am I the first one ever who have tried to connect an STM32 (or EFR32 in my case) with an MCP251x CAN controller ?
• Should I update the existing driver to be compatible with EDGE interrupt instead of LEVEL interrupts ?

Thanks,
Adrien M.

[ndrs-pst]

Ping @talih0, CC @henrikbrixandersen.
I'm curious too 😄.

[henrikbrixandersen]

• Should I update the existing driver to be compatible with EDGE interrupt instead of LEVEL interrupts ?

How would you change it? The MCP2518FD uses level-triggered interrupt lines (meaning the interrupt line is asserted as long as an interrupt flags is present). This is different from edge-triggered interrupts.

[adri1mart1]

I am definitely not sure because I'm not totally familiar with edge/level interrupt, however, I would probably think about switching the interrupt mode to EDGE, and force the driver to reprocess the code it needs to process if the interrupt is still active after a first process.

How would you do to setup a STM32 / EFR32 with this chip otherwise ?

[henrikbrixandersen]

... and force the driver to reprocess the code it needs to process if the interrupt is still active after a first process.

So basically treating a level-triggered interrupt as an edge-triggered interrupt. That's not a good solution, as it can lead to races in the interrupt handling code.

[adri1mart1]

I agree, however this is the only solution I can see right now. Any though on another one ?

[henrikbrixandersen]

Yes. Use hardware interfaces that match each other. If you need level-triggered GPIO interrupt support for a peripheral, use a microcontroller with support for level-triggered GPIO interrupts.

[ndrs-pst]

@henrikbrixandersen For example, STM32 also only supports edge-triggered interrupts (see this link).
So if the driver itself requires GPIO_INT_LEVEL_ACTIVE, it will hinder the usage with MCUs that only support edge-triggered interrupts.

Any chance that the driver provides the option to enable usage with MCUs that only support edge-triggered interrupts?
I may ping @erwango for some opinion about this.

[henrikbrixandersen]

You seem to focus on the GPIO controller driver not supporting level-triggered interrupts, but if the GPIO controller hardware does not support level-triggered interrupts, how do you expect to be able to use a level-triggered interrupt with that GPIO controller? We cannot change hardware capabilities in software, no matter how hard we try.

[ndrs-pst]

I understand your point. For STM32, when configured to both-edge EXTI, the hardware doesn't provide specific rising or falling edge information, so we need to read the GPIO to determine the current state, then find out if it's rising or falling.

Maybe the user can decide to use GPIO_INT_EDGE_FALLING via KConfig while accepting the risk of missing interrupts. ?

[henrikbrixandersen]

I understand your point. For STM32, when configured to both-edge EXTI, the hardware doesn't provide specific rising or falling edge information, so we need to read the GPIO to determine the current state, then find out if it's rising or falling.

That's racy too.

Maybe the user can decide to use GPIO_INT_EDGE_FALLING via KConfig while accepting the risk of missing interrupts. ?

Definitely not.

[adri1mart1]

Hello all,

An update on this topic. In the end, I finally choose a solution in which I completely remove the interrupt and use
polling of the pin. I agree with you henrik, this is not a good way to do it. However, for now, this is a solution
that suits my needs.

I could not easily change the hardware, I don't need important CAN bitrate so that's fine. I don't think there's
any change to bring to zephyr code, it's quite easy to spot when you're using the hardware that you have a misconfiguration
using GPIO_LEVEL_INTERRUPTS.

Regarding one of my initial question: "Am I the first one ever who have tried to connect an STM32 (or EFR32 in my case) with an MCP251x CAN controller ?"

The answer is (probabbly) yes with this particular configuration. According to some discussion with the HW team, this
MCP251862 component is mostly used with MPUs, when dealing with MCUs, most of the time you choose an MCU that has
internal CAN controler, or you may choose the MCP2515 which is not concerned by that.

I'm closing this topic, thanks for you explanations