2025-04-14 9:33 AM
Hi, I’m programming on stm32cubeide and I’m using a H755ZI-Q microcontroller.
I have a small problem with serial communication:
Through usart, I try to display the data of EVERY project on putty.
But I have several problems: the communication is only successful through USART3, using as active the "default" PINs like TX and RX, that is PD8 and PD9.
So this happens: with these two pins configured print, but with other pins (such as PB10 and PB11 which from the datasheet have configuration USART3_TX and USART3_RX) on putty no printing takes place.
Also with all other USART/UART, printing does not take place.
Can you help me? I could make a mistake or is there a function to be coded in order for the communication to take place?
Simon.
Solved! Go to Solution.
2025-04-15 11:58 AM
Yes, that should do the trick.
Make sure that you set it for 3.3V
2025-04-14 9:49 AM
welcome to the forum
Please see How to write your question to maximize your chances to find a solution - you need to give some more information about your hardware setup
@Simontom wrote:with these two pins configured print, but with other pins (such as PB10 and PB11 which from the datasheet have configuration USART3_TX and USART3_RX) on putty no printing takes place..
When you change the pin configuration within the STM32, due you also correctly recofigure your software and your external hardware to match?
@Simontom wrote:I could make a mistake
Indeed.
But we don't know and can't see what you have, or what you've done - so we can only guess has to what might be wrong!
2025-04-14 12:41 PM
Hi, thanks for the reply, I'll try to explain better.
The board is the NUCLEO H755ZI-Q, the STM32CubeIde version is 1.16.
The connection between the core and my computer is via USB, via the CN1 port.
The serial communication is via COM4 (to use it I use a baud rate of 115200).
I don't have a specific hardware configuration other than the one just listed, since this problem I talked about, happens with any code, without configuring other devices.
To be clear, this also happens to print a simple "hello world".
However I insert the code in question, which is not a simple "hello world", but anyway the result is the same.
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_USART3_UART_Init();
/* USER CODE BEGIN 2 */
printf("Inizializzazione DWM1001...\r\n");
if (DWM_Init(&huart3) != HAL_OK) {
printf("ERRORE: DWM1001 non collegato o inizializzazione fallita!\r\n");
} else {
printf("DWM1001 pronto per misurazioni ad alta precisione (1cm)\r\n");
}
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_StatusTypeDef status = DWM_GetDistances(measurements, &anchor_count);
printf("Stato: %d (HAL_OK=0)\r\n", status); // Debug
if (status == HAL_OK) {
if (anchor_count == 0) {
printf("DWM1001 connesso, ma nessun anchor rilevato!\r\n");
} else {
printf("DWM1001 risponde correttamente. Anchor rilevati: %d\r\n", anchor_count);
Print_Distances();
}
} else {
printf("ERRORE: Comunicazione UART fallita (codice: %d)!\r\n", status);
}
HAL_Delay(500); // Misurazioni ogni 500ms
}
/* USER CODE END 3 */
}
/* USER CODE BEGIN 4 */
void Print_Distances(void) {
char buffer[128];
printf("--- Distanze rilevate ---\r\n");
for(uint8_t i = 0; i < anchor_count; i++) {
// Formattazione con 2 decimali (precisione cm)
snprintf(buffer, sizeof(buffer),
"Anchor %04X: %.2f m (QF: %d)\r\n",
measurements[i].anchor_id,
measurements[i].distance_m,
measurements[i].quality);
HAL_UART_Transmit(&huart3, (uint8_t*)buffer, strlen(buffer), 100);
}
}
int __io_putchar(int ch) {
HAL_UART_Transmit(&huart3, (uint8_t*)&ch, 1, HAL_MAX_DELAY);
return ch;
}
/* USER CODE END 4 */
In case the device is not connected (therefore with a different HAL_delay state), it should ERRORE: Comunicazione UART fallita, but this only happens in one case, that is, if USART3 is enabled, and the enabled GPIOs are PD9 for USART3_RX and PD8 for USART3_TX, which are "preselected" by the board.
If I disable these two GPIOs from the IOC, enabling other GPIOs for USART3 that have the RX and TX functions (for example PB10 and PB11), nothing is printed on putty, even restarting the software, redoing the program run, both for CM7 and CM4 (I program on CM4 at the request of my professor).
Even if I use other USARTs/UARTs (clearly enabling them on the IOC), no printing occurs.
So the question remains the same as before, am I doing something wrong or are there functions to code to enable the USART configurations?
I hope I was as clear as possible.
Tell me if you need more information to be able to help me.
Best regards.
Simon.
2025-04-14 12:47 PM
The USART on the NUCLEO is physically wired to the ST-LINK's MCU, so you can't randomly change the selection to entirely different pins. If you use different pins, you'll need to attach a USB-to-CMOS Serial type adapter to access the new signals.
For a schematic for the board, go to the board's home page, and click on the "CAD Resources" tab
2025-04-14 12:52 PM
https://www.st.com/resource/en/schematic_pack/mb1363-h755ziq-d01_schematic.pdf
2025-04-14 12:59 PM - edited 2025-04-14 1:04 PM
Hello, thank you for your reply.
I don’t know if I understood what you said, but I’m not changing pins at random!
First of all, when I program on stm32cubeide and activate a configuration for usart, default pins are activated in the RX and TX mode , so I always use those in the case of USART2, USART1, UART4 etc.
Also when I went to change the pins, I first checked on the datasheet that they had the necessary procedure.
So they are not random changes.
What do you mean by "If you use different pins, you'll need to attach a USB-to-CMOS Serial type adapter to access the new signals" What is this cable?
Best regards.
Simon.
2025-04-14 1:11 PM
you agree that in the schematic, PD8 and PD9 are in that configuration, but in fact the problem is not them, these two pins work correctly.
Just one thing though, on the NUCLEO-H755ZI-Q, how can I connect them? correct me if I’m wrong, but in the diagram where all pins are represented, these are not there.
2025-04-14 1:16 PM - edited 2025-04-14 1:16 PM
What I'm saying is the pin choices are not driven by your imagination, but physical plumbing on the board you've chosen.
You can pick other pin pairs for USART3, but these aren't connected to anything that's going to output to your terminal application. You will need to physically connect something to these new pins to observe the output. This could be a scope or logic analyzer if that's sufficient to confirm the signals are present.
The H755 provide multiple ways to escape different peripheral pins, the AF (Alternate Function) mapping is described in the part data sheet. The wiring manifested on the board is best described by the schematic. You can see which are committed to specific functions, and which are still free to use, and access via the pin headers.
2025-04-14 1:35 PM
To escape PD8/PD9 you'll probably need to make/break some solder bridges so they appear at the Arduino D0/D1 header positions.
2025-04-14 3:00 PM
@Simontom wrote:Also when I went to change the pins, I first checked on the datasheet that they had the necessary procedure.
So they are not random changes.
The datasheet just tells you about the chip itself - not the external wiring on the Nucleo board.
The external wiring on the Nucleo board connects PD8,9 to the ST-Link's VCP.
So if you change your chip configuration to anything other than those pins, it will not be connected to ST-Link's VCP - therefore you will have to provide your own wiring to make that connection.
Or provide a different USB-to-UART bridge (thus, a different VCP).