PinMap error on STM32F429xI (inc. Nucleo F429ZI) in Mbed-OS 5.15.0

[soleilplanet]

Description of defect

Our customer is using STM32F429AIH6 in production device, and recently they tried to upgrade to Mbed-OS 5.15.0 and found that there are pin map errors on some of the pins they are using.
For example, they are using PG_7 to reset the NB-IoT modem (this pin is defined in NUCLEO_F429ZI), and they are seeing assertion error in pin_function:
\mbed-os\targets\TARGET_STM\pinmap.c
void pin_function(PinName pin, int data)
{
MBED_ASSERT(pin != (PinName)NC);
And this was called from gpio_init() -> gpio_set() -> pin_function(...)
Looks like it's because in those pins are not defined in PeripheralPinMaps.h, but somehow the same code worked in Mbed-OS 5.13.x and Mbed-OS 5.14.x with PeripheralPins.c.

Target(s) affected by this defect ?

Nucleo F429ZI
STM32F429AIH

Toolchain(s) (name and version) displaying this defect ?

GCC

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.0

How is this defect reproduced ?

just try to access some pins which are not exposed on the external connectors on the board but directly connects to the MCU, and with Mbed-OS 5.15.0

Note that this happens on a device which is already massively deployed on the field.

[soleilplanet]

@MarceloSalazar

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2495

[jeromecoutant]

Hi
You could maybe try #12186
Regards

[mprse]

It looks strange since GPIO HAL functions do not use pin-maps and generally GPIO HAL API is not affected by the static pin-map extension. The problem as @jeromecoutant pointed might be in the case of peripherals that allow when some pins are NC. This is because of pin_function() which is now used during initialization instead pinmap_pinout() and does not allow NC.

I tried to reproduce the failure using your instructions (Use PG_7 as GPIO) on NUCLEO_F429ZI, but without success. App code can be found below:

void test_app()
{
    gpio_t gpio;

    gpio_init(&gpio, PG_7);
    gpio_dir(&gpio, PIN_OUTPUT);
    gpio_write(&gpio, 0);
    gpio_write(&gpio, 1);

    printf("Hello! I'm alive.\r\n");
}

@soleilplanet Can you provide a specific code to reproduce this issue?

I also analyzed code where pin_function() is called to set up peripheral pins and I found that PR #12186 is incomplete. UART initialization is now ok, but serial_free() still calls pin_function() unconditionally and this must be fixed:

mbed-os/targets/TARGET_STM/serial_api.c

Lines 357 to 359 in dc63202

	// Configure GPIOs
	pin_function(obj_s->pin_tx, STM_PIN_DATA(STM_MODE_INPUT, GPIO_NOPULL, 0));
	pin_function(obj_s->pin_rx, STM_PIN_DATA(STM_MODE_INPUT, GPIO_NOPULL, 0));

@soleilplanet Is it possible that this is the reason of this issue?

[mprse]

Fix for serial_free() can be found here: PR #12237.

[soleilplanet]

@mprse the issue was observe on customer application with customer's own implementation of cellular driver, so let me communicate with them to see if they can share that. They basically extended our cellular stack and add the GPIO control when calling cellular device reset.
I've shared the two PRs to the customer; I'll keep this updated when they have the result.
Thanks for helping!

[jeromecoutant]

Hi @soleilplanet
Any good news ?

[0xc0170]

If this is still valid, it would be good to have a code snippet for us to reproduce. Just take the pin and call stack and make a small example to reproduce the issue.

there were couple of fixes that might have already fixed this one (as mentioned earlier here).

[jeromecoutant]

Let's close this issue ?
Thx

[jeromecoutant]

@0xc0170 let's close ?
Thx