cancel
Showing results for 
Search instead for 
Did you mean: 

Issue on USART3 communication with host laptop [STM32F103RB_Nucleo]

JPani.1
Associate II

Hello,

I have some issue to transmit and receive data with my laptop and a STM32F103RB Nucleo board, with picocom.

I use USART3 (remapped for Tx/RX to C10/C11) : please see code attached.

When I use a jumper to connect Tx and Rx directly on the board (loop), this code works.

But when I connect Tx and Rx to my laptop through a Serial/USB cable, it does not work any more :

  • laptop to MCU : the RX IT are triggered, but the data is not OK (byte received is 0xfe each time I send a char through picocom)
  • MCU to laptop : char received but incorrect value (that's a strange char, probably 0xff or something like that)

I have ensured that COM port settings are the same (baudrate, etc...) and it is OK. I have also tried several pin configurations, but without success.

Does anyone have an idea to help me ? 🙂 Thank you.

Julien

5 REPLIES 5
JPani.1
Associate II

Hello again,

Just to add some information abour my issue :

  • same issue on another PC (with Windows & Putty) -> so it's not a problem on host side
  • same issue with USART2 through ST-Link -> so i'ts not a problem with my cable
  • last but not least, same problem with the code taken from this website (where it seem's to work !) :

https://visualgdb.com/tutorials/arm/stm32/uart/hal/

[see code in chapter 6 -> I commented the line 26 before testing the code because of compatibility issue -> "//GPIO_InitStructure.Alternate = GPIO_AF7_USART2;"]

In all these cases, I only see weird characters in the serial terminal.

Unfortunately I do not have any scope at the moment, to check Rx and Tx signals...Could it be an issue with my board ? Or just something about my pin configuration ?

JPani.1
Associate II

Hi all,

I look at Rx and Tx signals with a scope. They seemed to be clean. So I compared both signals for a given char ('a') and I noticed that there were a ratio 2 between them. So I have configured picocom with a baudrate of 57600 (115200/2)...and it worked !

So, unless I do not got something, it means that a baudrate 115200 with UART_MODE_TX_RX corresponds to a baudrate 57600 for each of both signals...was it supposed to be obvious ? is it normal ? or is there something that is not correct in my code ?

Anyway, I'm glad for having found the issue. And maybe some people here will not waste so much time, thanks to this explanation. ^^

Bonne soiree !

Julien

>>So, unless I do not got something, it means that a baudrate 115200 with UART_MODE_TX_RX corresponds to a baudrate 57600 for each of both signals...was it supposed to be obvious ? is it normal ? or is there something that is not correct in my code ?

Not normal. More indicative of clocking being wrong, or HSE_VALUE definition not reflective of actual source clock. For external clock source use BYPASS mode.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
JPani.1
Associate II

Thank you for your help.

You're probably right. I must admit that I did not use the code generated automatically by CubeMX (which deals with clocks). I will check that.

JPani.1
Associate II

Confirmation : You were right.

I added a call to "SystemClock_Config()" function, as done in some code generated by CubeMX, and it works.

But I'm a little bit surprised : taking a quick look at clock tree in MCU doc, I would expect the value used in this function to be the default ones (HSI ON with all dividers set to 1).

Anyway, it works now and it is more consistent.

Thank you again !