STM32U575 LPUART: what am I missing?

[Rob Meades]

I have LL-API based UART/USART code which runs on an STM32U575 (tested on a NUCLEO-U575ZI-Q board), no problem (@ 115200).

I would like to move this code to the LPUART (pins D0/D1, PG8/PG7, of the board).  However, I have failed; not even TX works (a probe connected to PG7/D1 shows low all the time when I transmit data on the LPUART).

The changes I have made to my code are:

• Use the LL_LPUART_ functions instead of the LL_USART_ ones,
• Set AF8 for the pins,
• Use pin PG7 for TX (D1), PG8 for RX (D0),
• Call LL_APB3_GRP1_EnableClock().
• Select LL_RCC_LPUART1_CLKSOURCE_SYSCLK as the clock source for the LPUART (with LL_RCC_SetLPUARTClockSource()) so that it can achieve 115200.

All configurations functions with a return value (e.g. LL_LPUART_Init()) returned success.  What have I missed?

[Rob Meades]

Taking this down a level, I've hacked my code to configure pin D1, PG7, as a GPIO and toggle it in a loop: no toggling is seen by a probe connected to pin D1 on the NUCLEO-U575ZI-Q board.

As a sanity check, if I use the same code and change just the pin number to PF15, which appears on D2, the next pin along on the same connector, then toggling is seen by a probe connected to pin D2.

I must be doing something really basic wrong here.  All GPIOs are hung off the same AHB2 bus, so there shouldn't be a clocking problem.  There's nothing special about PG7 or port G, as far as I can tell, except possibly what VDD they work to on the board, but I'm seeing no movement whatsoever, not even to 1V8.  It seems like PG7 is just not coming out of D1.

I've checked the state of the solder bridges on the board: SB25 and SB27 both have zero-ohm resistors across them, SB24, SB26, SB31, and SB33 are open.

[Rob Meades]

And, sure enough, if I remove the hack in my code and just choose PA2/PA3 for TX/RX, instead of PG7/PG8, then all is good, my LPUART code works.

Is there something wrong with the D0/D1, PG7/PG8, pins on the NUCLEO-U575ZI-Q board?  I have tried this on more than one board now.

[Tesla DeLorean]

GPIOG, do you need to enable VDDIO2 for this to work?

HAL_PWREx_EnableVddIO2();

[Rob Meades]

You did it again Clive!  I didn't know I had to enable VDDIO2 to get Port G to run on a NUCLEO board: none of the examples do it and the user manual for the board mentions that Port G is powered from VDDIO2 but doesn't mention anything about having to enable it, or how to.

I have learned, and hopefully others will from your solution to this question.

[Tesla DeLorean]

Cube can obfuscate a lot of things, and the lack of comments doesn't help. The GPIOG/VDDIO2 thing is also on the L4+ devices, we used them to directly interface with cellular modems needing 1V8 signalling whilst other circuits wanted 3V3 (CODEC, SLIC, etc). Saves those auto-magic level shifters, and also allows for tri-stating the lines, which the TELIT modules were/are fussy about.

It's one of those recurrent "gotcha" issues along with PWR domain clocks. Some of the code needs more comments to re-enforce WHY it's being done, or secondary impacts.

/**
 * @brief Power Configuration
 * @retval None
 */
static void SystemPower_Config(void)
{
 HAL_PWREx_EnableVddIO2();

 /*
 * Disable the internal Pull-Up in Dead Battery pins of UCPD peripheral
 */
 HAL_PWREx_DisableUCPDDeadBattery();

 /*
 * Switch to SMPS regulator instead of LDO
 */
 if (HAL_PWREx_ConfigSupply(PWR_SMPS_SUPPLY) != HAL_OK)
 {
 Error_Handler();
 }
/* USER CODE BEGIN PWR */
/* USER CODE END PWR */
}

.  

[Rob Meades]

Indeed: I can see the use of it with our 1V8 cellular module interfaces, just need a pointer to realise there is a light switch I have to toggle somewhere to get me out of the dark :-).