Can't get the ST-Link-routed USART communication to work on the STM32F767ZI

[jdh]

I'm trying to print output to the console in the STM32 work bench, but I can't seem to get anything out, and with my lack of a logic analyzer the best I can do is confirm my calls to HAL_UART_Transmit return HAL_OK. Below is the minimal example I'm attempting:

int main(void)
{
	HAL_Init();
 
	UART_HandleTypeDef huart3;
	huart3.Instance = USART3;
	huart3.Init.BaudRate = 115200;
	huart3.Init.WordLength = UART_WORDLENGTH_8B;
	huart3.Init.StopBits = UART_STOPBITS_1;
	huart3.Init.Parity = UART_PARITY_NONE;
	huart3.Init.Mode = UART_MODE_TX_RX;
	huart3.Init.HwFlowCtl = UART_HWCONTROL_NONE;
	HAL_UART_Init(&huart3);
 
	HAL_UART_Transmit(&huart3, (uint8_t*)"HELLO\n", 6, 0xFFFF);
 
        // Confirms that execution passed the transmit
	BSP_LED_Init(LED2);
	for(;;){
		BSP_LED_Toggle(LED2);
		HAL_Delay(1);
		BSP_LED_Toggle(LED2);
		HAL_Delay(9);
	}
	BSP_LED_DeInit(LED2);
}

I've attempted to use both 9600 and 115200 baud across USART1, 2, and 3 (I found documentation that says 3 should be correct for routing to the ST-Link's virtual console). I'm also trying to maintain as minimal a toolset as possible (MXCube didn't work for some reason and I don't want to run mbedOS, just FreeRTOS).

I imagine I must be missing some sort of initialization or configuration, and if anyone could point towards some good documentation as well I would be extremely grateful. The best I can find so far is the unified Nucleo board reference and it doesn't contain much useful information about getting UART or USART working.

EDIT (some details):

Dev machine OS: Windows 10

Dev board: STM32F767ZI Nucleo

IDE/Debugger: System Workbench for STM32

Toolchain: Ac6 STM32 MCU GCC

Third-party libraries: FreeRTOS included but not called (yet)

[Tesla DeLorean · Accepted solution]

Enable clocks for UART and GPIO involved.

Configure GPIO pins and association with the UART.​

[Tesla DeLorean]

Check peripheral register settings in the debugger​

[jdh]

I saw examples that started the clocks, so I added this in accordance:

__GPIOA_CLK_ENABLE();
__USART3_CLK_ENABLE();

to no avail. I was also operating under the assumption that GPIO information would be handled by the HAL using the USART3 definition (a position in the peripheral memory mapping section). Is this incorrect?

EDIT/UPDATE: I also attempted to replicate the tutorial's pin initialization like so:

GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = GPIO_PIN_2|GPIO_PIN_3;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
GPIO_InitStruct.Alternate = GPIO_AF7_USART3;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Still nothing, though.

[jdh]

Good news! I made some serious progress and realized I'm dumb as heck. So for one, the pins are on port D, I was enabling the clock for port A, whoops! Also pins 8 and 9 are used, not 2 and 3, another big mistake. So now things are appearing in the console as I hoped, but it's all ASCII gibberish (áááá) so something still isn't quite right.

[Tesla DeLorean]

Make sure the define for HSE_VALUE is reflective of the 8 MHz used on the NUCLEO board, and not 25 MHz

[jdh]

It is indeed set to 8 MHz, courtesy of stm32f7xx_hal_conf.h

When I get a chance to tinker later tonight I'll be adjusting baud rates and settings to see if there's maybe just a disconnect in interpretation.

[Piranha]

Not only adjust HSE frequency, but also make sure HSE bypass is enabled. Confirm correct system frequency with a LED blinking once per second.

Configure USART baudrate and remember to set the same baudrate in terminal software on a PC side . 🙂

[jdh]

I've confirmed that the frequency is correct with the suggested 1sec blink rate, I've also ensured that the baud rates match on the terminal as well as the code, but I'm still getting gibberish out.

It appears as though the data line is not actually working correctly, I can reverse the string input and still get the same 'noise' out. Correction: this only occurs within the workbench, Tera Term shows different output for a different string. Strange.

Another strange clue: Tera Term only shows 2 bytes being received when I send 5 ("BEEF\n"), and what's received is absolute gibberish ("€%").

[jdh]

So the issues just keep multiplying. Sometimes I get more bytes than I send, sometimes I get fewer, and sometimes I get none at all (though repeated resets seem to get something sent, and it's always consistent like 3 with nothing, 1 with several bytes). In the most minimal case I can't even get a linefeed character to be sent correctly (though with some baud settings on some attempts I got newlines, but nothing I could really reproduce consistently).

Okay, so I happen to be extremely dumb. Turns out the ol' lesson that every systems-level and embedded-level prof teaches is very important: NEVER TRUST YOUR UNINITIALIZED MEMORY. The fix? Zero out the initialization structs. That's it. Some setting had garbage memory in it that screwed the UART initialization up. That's all, that was it, I can now print correctly and move on the a debug print utility.

Sorry for the absolutely inane questions and such, I'll mark the post with the answer the initial question as to close this thread out.