AnsweredAssumed Answered

[STM32746G-DISCOVERY] Problems with USART6 transmission

Question asked by Ivan Ivan on May 15, 2017
Latest reply on May 16, 2017 by Clive One

[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 25 of Board User Manual). In System 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 173.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.

Attachments

Outcomes