Problem with UART communication after bridges resoldering on Nucleo-F303RE

[Aster]

Hi,

During development of my project on Nucleo-F303RE, I noticed that there is no communication on my Arduino connector USART2 related pins, even thorugh I set it up in the STM32CubeIDE pinout configuration. Quickly I found out in UM1724 that these pins are by default not connected to the ST morpho and ARDUINO connector, due to the connection to ST-LINK MCU.

So I

>set up new USART3 on (pins PB10 and PB 11),

>set configuration exacly as USART2,

>flashed the board

>as in the user manual I soldered OFF 2 bridges (SB13 and SB14) and soldered ON 2 other bridges (SB62 and SB63)

I connected these pins (PB10 and PB11) to the CN3 Tx and Rx pins and I am able to download and debug the code. However, when I try to communicate with the board using putty terminal on COM3 (where the board is connected) with correct baudrate, I no longer can transmit any data from PC to the board and vice versa.
Due to the fact that I am able to flash and debug the board I assume that connection is set up properly.
I am trying to use simple program where i use the functions in the main loop:
           char data = '1';
           HAL_UART_Transmit(&huart3, &data, 1, 1000);
           HAL_Delay(3000);

And there is no response on putty terminal. The question is how can I communicate with my board using uart and putty terminal now?

PS. I want to still have the same posibility to write with the putty terminal to the board using uart connection, and having debug and flashing capabilities - just on different uart instance and pins. 

 

[TDK]

Debugging is done with SWDIO/SWCLK, not with UART of any sort. Programming over UART is possible with the bootloader, but that is not the normal Nucleo operation.

Are you confusing PB10/11 with PC10/11?

 

If the intention is to establish UART to the computer, why not just use the original PA2/PA3 and the existing VCP interface?

[KDJEM.1]

Hello @Aster and welcome to the Community :),

Besides, the reply shared by @TDK , I recommend you to take a look to this wiki STM32StepByStep:Step3 Introduction to the UART - stm32mcu.

Thank you.

Kaouthar

 

[Aster]

Thank you for replies.

@TDK thank you for clarifying that there is no UART needed to perform flashing on to the board. I am trying to switch default UART connection with PC to other pins on the board as Pins PA2 and PA3 will be wired with external devices so I need them to be available.

@KDJEM.1 also thank you for the response, however I didn't find anything that solved my problems here.
I spent more time on the problem and found out that UART communication over P2 and P3 pins is working with other devices like Arduino without any issues (I was using UART2 instance). However, I still can not communicate PC with the board using UART3 instance.

I thought that there is no difference between using different USART3 pins on the board as long as they are connected properly with the CN3. However, when I changed their position from PB10 and PB11 to PC10 and PC11 it started to register the incoming data via HAL_UART_Receive_IT and HAL_UART_RxCpltCallback, but incoming data is pure gibberish. It looks like when I send data over putty terminal to the board it populates my buffers with random data. Here is checklist of things that I have looked at to solve the problem:

- Correctness of baudrate on the PC and board sides

- Different baudrates (9600, 38400, 115200)
- Ammount of Parity, Stop and Data bytes on both sides
- Clocking of the uart

- Different uart instances (USART3, UART4)

- Different pins

- Different modes (intterupts and blocking mode)

- NVIC priorities

- Inside code baudrate configuration (to check whether there is no .ioc configuration generation bug)

All of these configurations failed for me. I am not able to read anything useful from the lane.
PS. 1) One more interesting thing - I am able to receive chars over the UART only when HAL_UART_Transmit_IT is inside while(1) loop. If it is outside the loop or not used in code at all there is no reception of any chars even though i am setting the HAL_UART_Receive_IT and proper callback the same as before (?!).
2) Terminal settings are the same as for USART2  before soldering and there weren't any communication issues.

[MikaelM]

Hello @Aster ,

 

I think you have mixed several things here.

1/ Usart2 is connected by default to ST-link and is getting used for code downloading. You have nothing to modify by default to work with.

If you want to use usart3 instead of usart2 to be connected to stlink then you have to do the following :

CN3 is here to indicate that you can use uart3 as stlink .

 

2/ BUT in your case, you want to use usart3 to communicate with an external tool (putty)

 

If you want to use UART3 to communicate with an external tool like putty you have to connect your pc with a USB/RS232 ftdi cable to pin PC10(TX) and PC11(RX). And not CN3.

be careful with the TX/RX cable and don't forget GND cable.

Please configure as well internal pullup or pulldown idle state if no external pull.

 

You could find previous info here :

https://www.st.com/en/evaluation-tools/nucleo-f303re.html#cad-resources

specific :

https://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf

and 

https://www.st.com/content/ccc/resource/technical/layouts_and_diagrams/schematic_pack/group2/5a/85/d6/9a/34/e2/47/1d/MB1136-DEFAULT-C05_Schematic/files/MB1136-DEFAULT-C05_Schematic.pdf/jcr:content/translations/en.MB1136-DEFAULT-C05_Schematic.pdf

 

Best regards

Mikael

 

 

 

 

 

 

[Piranha]

I think you have mixed several things here.

Usart2 is connected by default to ST-link and is getting used for code downloading.

Well, and the bold part of your explanation just increased the confusion. Especially for beginners coming from Arduino, where the UART indeed is used for code downloading. With a debugger like ST-LINK, of course, normally the code is downloaded and debugged through the SWD interface.

[Tesla DeLorean]

Isn't one of the issues here that the NUCLEO-64's generally combine the ST-LINK and Arduino shield comms on a single UART and you want them separated.

I'd likely disconnect the bridges and then route an alternate / available UART RX/TX pair to the CN3 points.

[Aster]

Thanks everyone for your answears.

It tourned out that all of these problems and abnormal behaviours were caused because of shorting of SB13 and SB14 bridges. After carefull investigation of schematic I was 100% sure that I am doing everything right in code and in hardware. I didn't notice this issue at first because it was really small solder leak.

Thanks again for all the asnwears - especially @MikaelM for sharing the schematics which brought me closer to the solution.