No external UART RX signal

[TScottt]

Reference

• Board: Nucleo-H753ZI (MB1364, ST-LINK V3, rev B)

Summary

We have an external UART sensor (WitMotion HWT9053 IMU) connected to the Arduino D0/D1 header pins on a Nucleo-H753ZI. The sensor is confirmed working on Arduino. We have verified all USART register configurations are correct at the hardware level. A full GPIO scan of every MCU pin (PA0–PG15) shows zero toggling signal from the sensor. We suspect a board-level routing issue (solder bridges) but need ST guidance.

---

Approach History

Phase 1: Custom STM32H7 Firmware

We wrote custom firmware using STM32H7 HAL to communicate with the sensor at 57600 baud via USART1 on PB6(TX)/PB7(RX). Console output via USART3 PD8/PD9 (ST-Link VCP) works correctly.

Phase 2: Porting Vendor F1 Reference Code to H7

We also ported the sensor vendor's official STM32F1 sample code to STM32H7 HAL. This scans all standard baud rates (4800–921600) and attempts to detect the sensor. Same result — zero bytes received.

Phase 3: Tested Multiple Pin Configurations

1. USART1 on PB6(TX)/PB7(RX) (AF7) — Arduino D1/D0 per UM2407 Table 21
2. USART6 on PG14(TX)/PG9(RX) (AF7) — alternate D1/D0 routing on some MB1364 configs

Both configurations: zero received bytes at all baud rates. Both cable orientations tested.

Phase 4: Register-Level Verification

We dumped all relevant registers and confirmed they are 100% correct:

USART1->CR1 = 0x0000002D  (UE=1, RE=1, TE=1, RXNEIE=1)
USART1->BRR = 0x006D      (correct for 921600 @ 100MHz PCLK2)
USART1->ISR = 0x006000D0  (TEACK=1, REACK=1, TXE=1, TC=1, IDLE=1)
GPIOB->MODER = 0xFFFFAEBD (PB6=AF mode, PB7=AF mode)
GPIOB->AFR[0] = 0x77000000 (PB6=AF7, PB7=AF7 = USART1)

Phase 5: GPIO Pin Activity Sampling (PB7)

We sampled PB7 (USART1 RX) 500,000 times in a tight loop:

PB7 sample: highs=500000 lows=0

Pin is permanently HIGH (idle). No UART start bits detected.

Phase 6: Full MCU GPIO Scan (All 112 Pins)

We scanned every GPIO pin on the entire MCU (PA0 through PG15), configuring each as input with internal pull-up, and sampling 100,000 times:

FULL MCU SCAN (PA0-PG15, 112 pins total):
  *** PA1: H=50774 L=49226 SIGNAL ***    <- Ethernet PHY RMII_REF_CLK (expected)
Scan complete.
NO other toggling pins found on entire MCU.

---

What We Have Confirmed

Item Status

Sensor works on Arduino (same unit, same baud, same wires)	Confirmed
Console UART (USART3 PD8/PD9 VCP) works correctly	Confirmed
USART1 registers 100% correct (CR1, BRR, ISR)	Verified via dump
GPIO MODER and AFR correct for PB6/PB7 AF7	Verified via dump
NVIC interrupt enabled for USART1	Verified
PB7 shows no signal activity (500K samples)	Confirmed stuck HIGH
Full MCU GPIO scan — no sensor signal on any pin	Confirmed
Tried USART1 (PB6/PB7) and USART6 (PG14/PG9)	Both zero bytes
All 9 baud rates tested (4800-921600)	All zero bytes
Both TX/RX cable orientations tested	Both tried
Clock config: HSE bypass 8MHz, SYSCLK 400MHz, PCLK2 100MHz	Confirmed good clocks

Hardware Setup

• Board: Nucleo-H753ZI (MB1364, ST-LINK V3, rev B)
• Sensor UART target: USART1 on PB6(TX)/PB7(RX) = Arduino D1/D0 on CN10
• Console UART: USART3 on PD8(TX)/PD9(RX) = VCP (working)
• External device: WitMotion HWT9053 IMU (3.3V TTL UART, confirmed working on Arduino)
• Connection: Direct wire — sensor TX to CN10 D0: pin 16 (PB7), sensor RX to CN10 D1: pin 14 (PB6), GND to GND

Questions for ST

1. Conflicts: Are there any known conflicts with PB6/PB7 on MB1364 (e.g., Ethernet, USB, ST-Link debug) that could prevent USART1 from functioning even with correct solder bridge configuration?
2. GPIO scan interpretation: Our full-MCU GPIO scan detected no signal on any of the 112 scanned pins (only PA1 Ethernet PHY clock). Does this conclusively indicate the external signal is not reaching the MCU die, or could there be a scenario where the signal reaches the pin but is not visible to a GPIO input read?
3. Alternative test method: Is there a recommended minimal hardware test to confirm that the CN10 D0/D1 header pins are electrically connected to PB6/PB7? (e.g., external pulldown on D0, read PB7 as GPIO input)
4. Known issues: Are there any known errata or board-level issues with USART1 on PB6/PB7 for the Nucleo-H753ZI MB1364?
5. References: Are there any STM32H7 UART bring-up examples, internal app-note snippets, or known-good MB1364 code/config templates that support can share for external sensor links?

[Ozone]

I am not affiliated with ST, to put that first. Although staff is active here.

> Conflicts: Are there any known conflicts with PB6/PB7 on MB1364 (e.g., Ethernet, USB, ST-Link debug) that could prevent USART1 from functioning even with correct solder bridge configuration?

Did you check user manual for the Nucleo board ?
Such instances are usually documented.

And did you check the board schematics ?
Recently, ST has moved those from the "Documentation" section to the "Design" section of the board's webpage.
I find the Nucleo documentation and schematics suboptimal and confusing, since they try to cover many/all variants in one document.

[AScha.3]

As i see in board circuit : on PB6/PB7 is not usart1 , but LPUART1 .

Did you setup the cpu configuration in CubeMX ?   or what you did to remap the uart's ?

[mƎALLEm]

Hello @TScottt and welcome to the ST community,

As shown in the table 21: D0 D1 are used for LPUART1 and not USART1:

From the board schematic:

So you can use USART2 on PD5/PD6 GPIOs:

PS: please avoid verbose request as we we can be lost in the understanding of the issue/question. You need to be concise with providing the necessary information.

[Ozone]

> PS: please avoid verbose request as we we can be lost in the understanding of the issue/question. You need to be concise with providing the necessary information.

I think this applies to quite a few other threads here as well.
Structure is not a replacement for content and conciseness.

[TScottt]

@mƎALLEm Thank you for the response. To be concise:

1. I am aware the manual's default label for D0/D1 is LPUART1. However, the STM32H753 datasheet allows PB6/PB7 to be multiplexed to USART1 via Alternate Function 7 (AF7). My code configures them to AF7.

2. The core issue is physical, not logical. Even if I switch the firmware to use LPUART1 (AF8) exactly as labeled, the physical PB7 MCU pin still reads a completely flat line on a logic analyzer while the external sensor is actively transmitting.

Since the external sensor works perfectly on an Arduino, but its signal physically dies before reaching the Nucleo's MCU die, are there default open solder bridges between the CN10 header and PB6/PB7 on the MB1364 Rev B board that would sever the electrical connection?

I will test USART2 on PD5/PD6 as a workaround in the meantime, thank you for the suggestion. Is this accessible from the Morpho pins or would i need to solder a header?

[AScha.3]

How about this idea: take a DMM and check continuity or connection from/for D0/D1 to PB6/PB7 .

Then you know. ...2 minutes later...

[Andrew Neil]

Remember that the D0/D1 lines are usually also connected to the ST-Link Virtual COM Port (VCP).

So you'd need to break that connection if you want to connect an external signal.

Again, as @Ozone said, see the schematics & the User Manual for details.

May be easier to just use other pins?

[mƎALLEm]

---

@TScottt wrote:

Even if I switch the firmware to use LPUART1 (AF8) exactly as labeled, the physical PB7 MCU pin still reads a completely flat line on a logic analyzer while the external sensor is actively transmitting.

---

It could be a hardware issue? We don't have your hardware to advice..

---

@TScottt wrote:

1. However, the STM32H753 datasheet allows PB6/PB7 to be multiplexed to USART1 via Alternate Function 7 (AF7). My code configures them to AF7.

---

But PB6 and PB7 are not exposed to Arduino D0/D1

---

@TScottt wrote:

n Arduino, but its signal physically dies before reaching the Nucleo's MCU die, are there default open solder bridges between the CN10 header and PB6/PB7 on the MB1364 Rev B board that would sever the electrical connection?

---

Please refer to the user manual of the board or its schematic.