Pin D06 on F7FeatherV2 is active high after Meadow reset.

[Peter-Moody]

Describe the bug In Public Slack's support channel kaarew (Korken) reported that D06 after restarting is always active high. This was seen on a F7FeatherV2 v2.d. I repeated the test and saw the same behavior. My test was conducted with Mono disabled (meadow runtime disable).

To Reproduce On Meadow restart measure the voltage on D06. It should be floating. However, the voltage I measured was 3.233v. Pulling D06 down with a 1K resistor only dropped the voltage to 3.172.

Expected behavior It is expected that, on restart of Meadow, D06 would be open not driven high.

[Peter-Moody]

Background PB13 on FeatherV1 is used for UART5 TX, on FeatherV2 PB13 is used for D06 and UART5 TX is PC12. Below board.h shows, RX is always the same for both V1 and V2 boards but, TX changes with version.

// UART5 (Meadow STM32F7 to ESP32)
#define GPIO_UART5_RX     GPIO_UART5_RX_1 // PD2
// Left the original '#define GPIO_UART5_TX' so modifying Nuttx code not needed
#define GPIO_UART5_TX     GPIO_UART5_TX_3 // PB13 - default
#define GPIO_UART5_TX_V1  GPIO_UART5_TX_3 // PB13 - F7v1
#define GPIO_UART5_TX_V2  GPIO_UART5_TX_1 // PC12 - F7v2 & CCMv2

What I found

The first step is in espcp_coprocessor.c where the function espcp_early_init() correctly uses the hardware version information to set _active_pins to &_f7v2_pins if the board is a FeatherV2 or CCM. A bit later the function espcp_gpio_init() (same file) uses this information to configure PB13 as UART5's TX pin. So far all is good.

Afterward, hcom_esp32_network_monitor.c starts a thread and this thread calls the Nuttx function open() to open /dev/ttyS2. Nuttx then calls uart_open() in serial.c which, in turn, calls code in stm32_serial.c and eventually calls up_setup(). Within up_setup() UART5's RX and TXpins are configured and PB13 becomes UART5s TX pin which is wrong for FeatherV2.

This maybe an easy fix or there may be other considerations I am not aware of.