MRO Control zero h7 oem GPS1/UART4/ttyS2 TX not starting

[carlosmurphyDragoon]

Describe the bug

MRO Control Zero H7 OEM 1.13.2 stable (master as well)
I'm attempting to use the GPS1/UART4/ttyS2 port as a generic mavlink connection. As verified via oscilloscope and a microcontroller connected to the port I am not getting any data on the TX pin. The FC is successfully reading the data being transmitted on the RX port, but UART4 TX shows zero activity. You can get the port working by running:
mavlink stop -d /dev/ttyS2
mavlink start -d /dev/ttyS2
Then everything starts working exactly as one would expect it. If those two lines are placed in the /etc/extras.txt file on the SD card everything works from boot as well.
The RX side on the FC is definitely working, if you configure the mav_mode as custom (no/few default streams) and then request specific streams on UART4 they will appear in the list from "mavlink status streams" but still show zero activity on the TX pin. I am also getting all the streams forwarded down to QGC as you would expect.

UART4 is somehow booting up in RX only mode, or more likely I suspect something is misconfiguring the PA0 pin it is on. potential suspect is GPIO_USART2_CTS which COULD use PA0 but in the board.h file it is defined as GPIO_USART2_CTS_NSS_2 which should be PD3. i'm grasping at straws though.

To Reproduce

Steps to reproduce the behavior:
1 turn on FC
(setup GPS1 serial port as mavlink port)
2 GPS_1_CONFIG = disabled
3 MAV_1_CONFIG = GPS1
4 MAV_1_MODE = Onboard (as default)
4 SER_GPS1_BAUD = 57600 8N1
(reboot whenever needed to get this params set)
5 no data comes out on the mavlink TX pin
you can verify the mavlink instance is started and has streams on it via the mavlink console:
mavlink status
and
mavlink status streams
will show a active mavlink instance and list streams but nothing coming out of the TX port

This can be see with a bare autopilot not connected to anything and checking for TX pin activity with a scope.

[lgarciaos]

Hi @carlosmurphyDragoon, we were able to reproduce this behavior on our reference boards. We will have a look into what could be causing this issue. For now you you may get around with your described procedure or use another port altogether, is there a particular reason to use UART4 as a serial only? There are UART6, UART7 and UART8 (labeled as FrSKY in-out) available as well.

[carlosmurphyDragoon]

@lgarciaos only because I spun a board with that UART connected to another MCU. The work arounds are fine for now, just wanted to make sure this weird issue was brought up.