cancel
Showing results for 
Search instead for 
Did you mean: 

[STM32746G-DISCOVERY] Problems with USART6 transmission

Ivan Ivan
Associate II
Posted on May 15, 2017 at 11:30

[STM32746G-DISCOVERY] Problems with USART6 transmission

Hello. I'm trying to communicate

STM32746G-DISCOVERY board with PC by using a USART6 (discovery has connectors for USART6, as seen in Figure 25of Board User Manual). InSystem Clock Configuration routine I have such lines considering USART6:

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART6;
 PeriphClkInitStruct.Usart6ClockSelection = RCC_USART6CLKSOURCE_SYSCLK;
 if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
 {
 Error_Handler();
 }�?�?�?�?�?�?

I have enabled timers for ports:

 __HAL_RCC_GPIOC_CLK_ENABLE();�?

I initialize my USART6 like this:

static void My_USART6_Init(void) { 
 __HAL_RCC_USART6_CLK_ENABLE();
 GPIO_InitTypeDef GPIO_InitStruct;
 /**USART6 GPIO Configuration 
 PC7 ------> USART6_RX
 PC6 ------> USART6_TX 
 */
 GPIO_InitStruct.Pin = GPIO_PIN_7|GPIO_PIN_6;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_PULLUP;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF8_USART6;
 HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
 //now comes the initialization of USART6 params
 //USART6->BRR = 0x57e2; //baud rate. calculated as in p1002 MCU_ReferenceManual for PCLK2 as source (108MHz)
 USART6->BRR = 0xAFC4; //SYSClk is source (216Mhz). Table 1, line 1 of MCU reference
//USART6->CR2 |= USART_CR2_MSBFIRST; //Most significant bit first. Might be useful when data is received incorrectly. p1033
 //stop bit is set in CR2. keep it default, 1 stop bit
 //USART6->CR3 |= USART_CR3_OVRDIS; //This bit is used to disable the receive overrun. Might be worth setting
 //p1029
//M1(bit28)M0(bit12) -> 0;0 (1 Start bit, 8 data bits, n stop bits) Keep default, no change
 USART6->CR1 |= USART_CR1_OVER8; //oversampling=8. involved in calculation of baud rate.
 USART6->CR1 |= USART_CR1_RE; //enable receiver
 USART6->CR1 |= USART_CR1_TE; //enable transmitter
 USART6->CR1 |= USART_CR1_UE; //enable USART6
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

I wrote also subroutine for sending byte

void LL_SendByteUSART(uint8_t data) {
while(!(USART6->ISR & USART_ISR_TC)); //Wait for TC bit in SR Register
 USART6->TDR=data; //write data to UART register
}�?�?�?�?

My main cycle looks like this:

while (1) {
LL_SendByteUSART('H');
 LL_SendByteUSART('e');
 LL_SendByteUSART('l');
 LL_SendByteUSART('l');
 LL_SendByteUSART('o');
 LL_SendByteUSART(' ');
 LL_SendByteUSART(':');
 LL_SendByteUSART(')');
 LL_SendByteUSART('\n');
 HAL_Delay(100);
 }�?�?�?�?�?�?�?�?�?�?�?�?

I am expecting to recieve such byte sequence in cycle, but instead my program transmits quite a gibberish, but not an expected ASCII bytes; and only once at program startup (I have screen attached). It may be seen also that software on PC reports about frame error. That software is quite reliable and popular.

What is wrong?

Bundled example (two boards transmitting data) works in a similar manner, data is unreadable on PC. HAL highlevel example generated from stm32Cube does not transmit a thing. Changing clock source for USART6 has no result. System Clock Frequency is 216Mhz, other components of bigger project work OK with this value. Having USART working is really important.

#usart6 #stm32746g-discovery
5 REPLIES 5
Posted on May 15, 2017 at 17:43

I would use TXE, not TC. Try sending a stream of 'U' characters and probe the TX signal with a scope, and validate the bit timings you are seeing.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on May 15, 2017 at 21:13

Hi Ivan,

If you're having issues with uart communication, you should try to make an example code using cubemx and the virtual serial port that is embedded in the discovery board, I checked the user manual and this port is attached to the pins PB7 and PA9 that correspond to USART1, and also you have an user switch that is in pin PF11, it is normally in Low level and pass to High when you press it.

In this thread I posted an example code, just change the configuration for the pins of your discovery board. If you want yo check the code of the peripherals initialization, you can check it on your IDE.

https://community.st.com/0D50X00009XkXrmSAF

Ivan Ivan
Associate II
Posted on May 16, 2017 at 12:11

Thank you for replies!

Forgot to mention about my hardware installation. I have connected USART6RX output (D0) to TX line of RS232 plug, 

USART6TX output (D1) to RX line of RS232 plug, Ground goes from CN7 connector to RS232 plug with wires. RS232 plug is connected to USB-to-RS232 stock cable (a popular one, produced by FTDI). USART6 should be used, it is defined in device's design (it is created by other )

Some people here gave an insight that the problem persists because of the different signal lvls: about 3V on controller output, but COM port operates with 9V as logical 1. They suggested that I should have another converter controller in between. They have even suggested that some of the used (RX and TX) pins might have been damaged by 9V from FTDI's converter!

I am new with electronics, but I'm not sure about it...

Posted on May 16, 2017 at 15:42

Hi Ivan,

Well, with that description I'm agree with your friends, the pins could be damage. When you use a RS232 converter, you don't have to plug the microcontrollers pins directly for what your friends said, voltages levels. The right way to connect the micro with the usb-RS232 converter is using a MAX3232 as show the following image:

0690X00000603TOQAY.jpg

Well, when say Raspberry goes your microcontroller or board. I prefer don't use those kind of converters, instead I use a USB-to-Serial converter like this one:

0690X00000603qTQAQ.jpg

https://www.aliexpress.com/store/product/FT232RL-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port-3-3V-5V/1406657_2043815349.html

 

The outputs levels are configurables to 5V or 3.3V with the jumper and you can connect directly to your micro. I suggest to you to make the rigth connections with the MAX3232 if you are still using the RS232 converter or try to acquire the serial converter and make a test with other USART.

Posted on May 16, 2017 at 18:07

As Elkin points out, there are USB-to-CMOS Serial converters, these are actually more prevalent the ones that also include the RS232 level converters, as most MCU and GPS type modules natively interface at CMOS levels, and RS232 is really just for external connectivity to other systems.

I would generally recommend the use of SiLabs parts, there are a lot of fake FTDI parts in the channel, and FTDI as a company has released broken and damaging drivers. I also see Prolific drivers Blue Screen my systems.

SiLabs CP2120 boards are readily available on eBay and Amazon platforms for under $4 shipped.

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