How to NUCLEO64, UART and Printf output?

[PaulSwanson]

Hello,

I want to use UART2 on a NUCLEO-L073RZ for printf output but cannot

get it to work for the life of me, please help.

Context:

In this scenario, I need the UART2 output direct from the PA2 / PA3

pins on the ST Morpho header (CN10), in other words, not from the

Tx / Rx pins on the ST-Link debugger.

So, according to UM1724 Section 6.9, I've soldered closed SB62 and

SB63, and, I've also removed the 0ohm resistors from SB13 & SB14.

Problem:

I've tried various code bases for configuring and enabling printf

output over UART2, but for the sake of clarity and uniformity, I've

tested the CRYP_AESModes example source code, as published in the

NUCLEO-L073RZ module from ST and cannot get ANY discernible output

from UART2.

To test the output I have my standard FTDI USB module, tested and

working with various other boards, wired up appropriately with

Tx / Rx / GND as usual, however, there is no visible or measurable

activity over the pins. Also, according to RM0367 Section 29.5,

Tx should be high when enabled yet inactive, however, it is not.

I'm very much at a loss here where to go next.

What am I missing?

Does anyone have some nice, simple "Hello, world" level source code

for a NUCLEO board I could reference?

I just want to be able to output over USART, it's usually a trivial exercise on most other platforms I've worked on.

Any help appreciated.

[Nikita91]

Is this a printf or UART configuration problem?

Do you have output on the stlink debugger ?

What appens if you write a char directly in uart register: UART2->DR = 'a' ;

if you don't receive 'a', the uart is misconfigured.

[PaulSwanson]

Hi Nikita91,

That's a good question. I believe it's a UART problem.

I have the solder bridges on the board configured so that the Tx / Tx pins are isolated from the debugger, which is what I need. And I've checked the Tx/Rx pins on the debugger and they don't seem to be active, which is good.

I might try that test you suggested. However, if the UART is misconfigured then it is the example code from ST that is broken ... that and every other similar piece of code I've tried. Seems unlikely.

[Peter BENSCH]

Hi, Paul,

this has already been discussed several times, e.g. here.

printf calls __io_putchar() resp. fputc() which needs to be defined somewhere. Please do not forget to include <stdio.h>.

With HAL you could e.g. paste into USER CODE 4:

#ifdef __GNUC__
 #define PUTCHAR_PROTOTYPE int __io_putchar(uint8_t ch)
#else
 #define PUTCHAR_PROTOTYPE int fputc(uint8_t ch, FILE *f)
#endif // __GNUC__
PUTCHAR_PROTOTYPE
{
 // Place your implementation of fputc of one character here
 //use a reasonable timeout, e.g. 2.2ms for 10.5bit at 4800Bd (8bit + 2.5bit start/stop)
 HAL_UART_Transmit(&huart2, &ch, 1, 3);
 return ch;
}

When your question is answered, please close this topic by choosing Select as Best.

/Peter

[PaulSwanson]

Hi Peter, thanks for replying.

As I said in my original post, I'm using ST supplied example code for this board, so it naturally includes what you've covered, plus all the other necessary boilerplate code to initialise UART and the like.

The problem, as described, is that the code simply is not providing any measurable output on PA2.

Do you have any ideas about why this is?

Thanks.