cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with debugging on USART1 using X-NUCLEO-NFC05A1 and NUCLEO-F401RE

Simon R.
Associate II

Hello all,

I will start by saying that I am new to STM32 development and that your patience is very appreciated for what I hope is a simple problem.

I am working with a X-NUCLEO-NFC05A1 mounted on a NUCLEO-F401RE.

I have successfully imported the example project 'Polling' from the X-CUBE-NFC5 software expansion into Atollic TrueStudio and have uploaded the code to the board.

The behavior of the compiled code is apparently identical to that of the included binary; everything seems to be working fine in the default configuration.

The 'Polling' project has USART debugging on USART2 by default. This is a bit of a problem because in order for the USART2 pins (PA2 and PA3) to be accessed from the NUCLEO-F401RE expansion board's headers, SB62 and SB63 must be closed (I've verified that this works and that I can read USART2), but doing this sacrifices the ST-Link functionailty (which I want to retain).

This topic is discussed here: https://os.mbed.com/forum/platform-34-ST-Nucleo-F401RE-community/topic/4949/?page=1#comment-24785

So what I would like to do is use the debugging function 'platformLog()' in the 'Polling' project with USART1 (or USART6) rather than USART2. The issue is that I am having trouble changing it successfully. In my attempts to change it, I have never gotten any signals from the USART1 pins in my 'Polling' project, though I am able to do so if I start a project from scratch.

In other projects, I can read USART1 traffic from the pin headers (even with the NFC05A1 expansion board on top of the NUCLEO-F401RE). So I think it is a coding issue on my side.

I will include the main.c of the unaltered original project (in which USART traffic is successfully sent over USART2) and also my unsuccessful attempt at changing the debugging to USART1 (in which no USART1 signal is seen on a logic analyzer).

Unaltered file is called main_original.c and altered file is called main_altered.c

A list of the changes I made:

line 60: replace 'UART_HandleTypeDef huart2;' with 'UART_HandleTypeDef huart1;'

line 71: replace 'static void MX_USART2_UART_Init(void);' with 'static void MX_USART1_UART_Init(void);'

line 101: replace 'MX_USART2_UART_Init();' with 'MX_USART1_UART_Init();'

line 108: replace 'logUsartInit(&huart2);' with 'logUsartInit(&huart1);'

line 242: create function MX_USART1_UART_Init to replace the USART 2 verison

approx. line 330: prevent PA9 and PA10 from being initialized as analog pins (could somebody tell me if this step is necessary or should MX_USART1_UART_Init() take care of it?)

I must be missing something, any pointers?

Thanks very much!

1 ACCEPTED SOLUTION

Accepted Solutions
Mike_ST
ST Employee

From what you shared, I would say that might be not enough, you have to configure pins.

Please try to find a HAL_UART_MspInit function inside the file stm32f4_hal_msp.c

You may find your answer there.

View solution in original post

3 REPLIES 3
Ulysses HERNIOSUS
ST Employee

Hi Simon,

your mentioned thread on mbed merely means that if you want to drive the USART pins externally you need to disconnect the pins from STLink.

One of the functions of STLink is a USART bridge. By disconnecting the USART you will loose that functionality but not the ability to debug/program.

I am not expert on the USART pin configuration - maybe someone else can give you here an answer.

Also removing ST25.. tag from this thread because it is only about USART on Nucleo board.

Regards, Ulysses

Mike_ST
ST Employee

From what you shared, I would say that might be not enough, you have to configure pins.

Please try to find a HAL_UART_MspInit function inside the file stm32f4_hal_msp.c

You may find your answer there.

Hi Mike,

You were spot on: my HAL_UART_MspInit function was missing an if statement with gpio and clock configuration settings for USART1. I simply copied it from a functioning project into this one and it worked. Thanks very much!