2025-02-18 06:23 AM
Hello,
So right now I am trying to get my printf to work on CubeIDE and printing the respective output on PuTTY. I can't seem to figure out why it doesnt work when people on Youtube simply press run and their code works.
For context...
1. Using M7 core and running USART3 in async mode with
a) Baud Rate: 115200 Bit/s, 8 Bits, no Parity, 1 Stop Bit
b) Checked USART3 global interrupt
c) Checked pin config (no overlap)
2. In Putty
a) Checked all parameter match
b) COM port matches
Nothing seems to print in PuTTY although it does connect. If any more information is required I will send immediately. Thanks in advance!!
This is the pseudo code of what I am trying to run
#include "main.h"
#include "usart.h"
#include <arm_math.h>
void SystemClock_Config(void);
void PeriphCommonClock_Config(void);
int main(void)
{
HAL_Init();
SystemClock_Config();
PeriphCommonClock_Config();
HAL_HSEM_FastTake(HSEM_ID_0);
HAL_HSEM_Release(HSEM_ID_0,0);
MX_GPIO_Init();
MX_DMA_Init();
MX_I2C1_Init();
MX_QUADSPI_Init();
MX_I2S1_Init();
MX_SPI3_Init();
MX_USB_OTG_FS_PCD_Init();
MX_USART3_UART_Init();
while (1)
{
/* USER CODE END WHILE */
// printf("success");
HAL_UART_Transmit(&huart3, (uint8_t*) "Good", 3, 100);
HAL_Delay(1000);
/* USER CODE BEGIN 3 */
}
}
extern "C"
{
int _write(int file, char *ptr, int len)
{
HAL_UART_Transmit(&huart3, (uint8_t*)ptr, len, HAL_MAX_DELAY);
return len;
}
}
2025-02-18 06:42 AM
I would recommend to start with finding out what is actually "there".
Use a scope or logic analyzer, and check if there is a signal on the MCU Tx pin.
I don't know the board you use, but make sure this MCU Tx/Rx pins are correctly hooked up to a serial-USB converter (or level converter), and connected to the proper PC pins (i.e. crossed).
And check with the schematics the used MCU pins are free, and notused by other, external components.
And finally, check the transmission parameters settings on both sides (baudrate, start/stop bits, parity), and verify (i.e. measure) on the transmitting side.
Transmitting something continuously in an endless loop is a good starting point for that.
> Nothing seems to print in PuTTY although it does connect.
That does only mean the terminal program (Putty) was able to open the serial line / COM port with the supplied parameters, and nothing else.
2025-02-18 08:03 AM
Omg brilliant! I just realized that the pins weren't connected for the USART. Thanks for pointing that out!
Right now, I'm working on a custom board, and I’d like to ask are there any alternative ways to log data from STM32CubeIDE? I know SWO and RTT could work, but is there a more straightforward method that doesn’t require a UART-to-USB converter? Maybe logging directly via USB or using CubeIDE tools?
2025-02-18 08:06 AM
@Goldylux wrote:is there a more straightforward method that doesn’t require a UART-to-USB converter? Maybe logging directly via USB or using CubeIDE tools?
You certainly could implement something to go over USB; eg, CDC.
Whether that would actually work out as "more straightforward" is another question ...
2025-02-18 10:36 PM
First, many STM32 boards have one set of target UART pins routed to the onboard ST-Link.
And this ST-Link in turn register both as debug adapter and COM port.
So, for most boards (check the schematics !), you don't need any external connections for serial output.
> Right now, I'm working on a custom board, and I’d like to ask are there any alternative ways to log data from STM32CubeIDE?
Yes, there is - the so-called semihosting.
Not sure if and how this is realized in CubeIDE, you would need to check the documentation.
I use Segger Embedded Studio for such purposes, which is free for private use.
Semihosting uses the debug connection (JTAG/SWD), and requires support both from target and the host (PC).
Usually, you enable semihosting in the project creation "wizard", and the IDE adds the required library and code.
In your application, you then use "printf()" like functions as you would in a host-based console application, and the output is routed to some debugger output window.
Use with great care, as it has a significant impact on the application timing.
But it is very useful in debugging and validating most functionality.
Most IDEs now set up a debug and release "branch" of your project, and it is common practice to use semihosting output only in the debug code.