Mbed-os: missing GPIO ports and pins definitions on STM32L4

[pmancele]

Description

• Type: Bug
• Priority: Blocker as we cant use some pins on the STM32L476ZG

---

Bug

Target
STM32L476ZG (which has 144 pins)

mbed-cli version:
1.0.0
mbed-os version:
last commit of master 21b91c794eb21b06aba2be28111a85f19b3fa5e3

The issue
We want to declare DigitalIn, DigitalOut, I2C, etc... on some pins of GPIOG port of a STM32L476ZG which has 144pins. But all the functions to activate the GPIO clock are not present in the file mbed-os/targets/TARGET_STM/TARGET_STM32L4/pinmap.c
Se we add the missing one for GPIOF and GPIOG clocks.
We also created a target for our MCU in the directory STM32L476xG, based on the NUCLEO_STM32L476RG files which has 64 pins. So we add the missing pins defintions in PinNames.h and PeripheralPins.c

We can compile, debug and program our target. Everything works fine except when it comes to work with G port.
We cant get any output nor input on pins of G port. We checked the MCU registers and the registers corresponding to GPIOG are well modified so as the clock registers which indicate that GPIOG clock is active.
What do we miss ? is there others files to modify in order to use a GPIO port that wasnt defined ?

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[adustm]

Hello @pmancele
It's good to read that you are adding a new platform in mbed-os. Thank you for that.

I just discovered your question on https://developer.mbed.org/forum/bugs-suggestions/topic/27353/?page=1. Sorry I did not see it before.
Please be aware that we have reorganized the TARGET_STM32L4 folder to help our customers to reuse our startup files for instance. There is no more L476_L486 directory, but a new TARGET_STM32L476xG in which you may put your target files. Add STM32L476xG in the targets.json definitions and mbed will find them at compilation time.

Back to your problem, I think I've found the bug:

I've read the datasheet for this device to see what is specific to GPIO port G. I've seen that PG2 to PG15 are supplied with and external VDD (VDDIO2)

Then the STM32L476ZG Reference Manual chapter 5.1.2 Independant I/O supply rail explains that you are supposed to activate it by a specific bit in PWR_CR2

After reset, the I/Os supplied by VDDIO2 are logically and electrically isolated and therefore
are not available. The isolation must be removed before using any I/O from PG[15:2], by
setting the IOSV bit in the PWR_CR2 register, once the VDDIO2 supply is present.

Our code in mbed does not activate this bit because we did not have a GPIO port G for STM32L476RG device. This explains why your target works in STM32Cube
Looking at STM32Cube code, I can see that my colleagues write this bit at the clock init of the pins.
I think that you should add in your file https://developer.mbed.org/media/uploads/peyo/pinmap.c

__HAL_RCC_PWR_CLK_ENABLE();
HAL_PWREx_EnableVddIO2();

like this:

#if defined(GPIOG_BASE)
        case PortG:
             __HAL_RCC_PWR_CLK_ENABLE();
            HAL_PWREx_EnableVddIO2();
            gpio_add = GPIOG_BASE;
            __HAL_RCC_GPIOG_CLK_ENABLE();
            break;
#endif

I hope it will help. Let me know. If it works you will have the oppotunity to push this modification in mbed-os repository, or we will do it ourselves.

Kind regards

[helmut64]

As STM32L4 has now many different L4 MCU's where the difference is mainly the pinout, my idea is to make all tables in "PeripheralPins.c" weak symbohls which means we can overwrite this if needed.

This would allow mbed clients to choose a mbed supported board with a matching SRAM, and updated the PeripheralPins table in their own code. The benefit would be that the great online compiler can be used.

PS: The ARM mbed compiler produces 40% smaller code which is also faster compared to the offline gcc. Also the learning curve is much easier with the mbed online IDE, it’s integrated help, etc.

[pmancele]

Hello
Thank you very much @adustm for your helpfull answer ! It seems that we missed that in the reference manual of the STM32L476ZG..

I created a push request as you recommended (This is my first one, i hope it respects the contribution guidelines)

Kind regards,

Pierre-Marie

[adustm]

Hello @helmut64,
Your idea is very interesting. Do you think that you could create a branch or a pull request so that we can review it ?
Kind regards

[helmut64]

@adustm Dear Armelle , yes I will create a branch and implement and test weak PeripheralPins.
Regards Helmut