stm32 GPIO driver

[tobiasjaster]

When trying to try GPIO functionality (/dev/gpio) on my STM32's I have a hard fault on both the Nucleo-L496ZG and the Nucleo-F767 with the proximity configuration.

The stack says 100% and the cause is apparently an "unexpected irq".

Does anyone know the error? And is there a reason why the arm configurations do not use the CMSIS and the STM32 do not use the STM-HAL?

[acassis]

Hi @tobiasjaster

I don't see the boards/arm/stm32l4/nucleo-l496zg/src/stm32_gpio.c file to support user GPIO on this board, so it needs to be added first.

About your question why not use CMSIS or STM-HAL, there is an old thread here about it: https://nuttx.yahoogroups.narkive.com/QxSBuUvM/cmsis

In theory it is possible to use some vendor HAL (new Espressif RISC-V chips are done this way), but I think for historic reasons Mr. Greg always developed the MCU support from scratch.

You could think this work is very painful (and in fact it is), but that bring a level of similarities among all ARCHes supported by NuttX. Also it forces you to learn more about the MCU low level, so you will really know almost everything about it.

[patacongo]

In theory it is possible to use some vendor HAL (new Espressif RISC-V chips are done this way), but I think for historic reasons Mr. Greg always developed the MCU support from scratch.

STM32 originally had a restrictive license that prohibited use of the code in NuttX. They loosened that license but only after many years after we established our own. I prefer ours better. it fits in and is common with other architectures and follows the coding standard. Why would you ever change that?

[tobiasjaster]

My thought was that ST is constantly developing its Hal and it is relatively well tested and integrated. According to the documentation some drivers are still missing for STM32. By integrating the HAL, these would perhabs more easily get along (so it is made with mbed os). But the care of the external dependence is naturally a point.

I ported the stm32_gpio.c from the Nucleo-L476rg. But as written, with both boards it comes with the integration to the same error, why here the thought with the HAL maintained by ST came to me.

[acassis]

@tobiasjaster this error cannot be related to the GPIO pin definition. Are you using GPIO input with interruption?

[tobiasjaster]

@tobiasjaster this error cannot be related to the GPIO pin definition. Are you using GPIO input with interruption?

This is unfortunately my big problem. I have only one GPO or GPI pin defined, nothing with interrupts, but I still get an interrupt error.

Unfortunately the error dump here doesn't tell me more (for example, which vector it was exactly). I also tried to get some debug messages between my console, but that was also unsuccessful. Strangely also dmesg ended here without any line with logs (if I take out the GPIO initialization, I get into the shell).

[acassis]

@tobiasjaster did you enable CONFIG_DEBUG_IRQ_INFO ? It should dump enough info.

Also looking the source code it seems that someone already added DEV_GPIO support to nucleo-l476rg board, if you have this board, please test on it first. This way you could confirm that the GPIO support on STM32L4 still working (or not) and you could this as comparison board.

[acassis]

@tobiasjaster any news?

[tobiasjaster]

Thank you for asking. I don't remember exactly what I did, but I tried it again on my Nucleo-l767 with the original nsh-config and it worked. Then I ported it again to the Nucleo-l496 and now it works. Must have been somewhere on my side. So the issue can be closed by me.

PS: My setup is a stm32-L496 with two MCP-GPIO expanders. To decouple all GPIOs cleanly from the device drivers via /dev/gpio, I have now written an expander for stm32l4. Is there a reason why something like this doesn't exist yet, or does it make sense to revert this as a PR?