STM32F407 - USART6 Tx Frame Error

ygt_1108 · ‎2017-10-18

Posted on October 18, 2017 at 10:31

Hi All,

I tried to use USART6 but the data I sended is corrupted, I check the baudRate bur its looks fine(9600 bps), I add the screen shot of oscilloscope I send 0x79(0b0111 1001) but its showed me irrelevant data, also I tired the diffrent baudrate but result was same,

Here is my USART6 initialization code;

GPIO_InitTypeDef GPIO_InitStruct;

USART_InitTypeDef USART_InitStr;

RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART6, ENABLE);

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE);

GPIO_PinAFConfig(GPIOC, GPIO_PinSource6, GPIO_AF_USART6);

GPIO_PinAFConfig(GPIOC, GPIO_PinSource7, GPIO_AF_USART6);

GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;

GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_UP;

GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF;

GPIO_InitStruct.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7;

GPIO_InitStruct.GPIO_Speed = GPIO_Speed_100MHz;

GPIO_Init(GPIOC, &GPIO_InitStruct);

USART_InitStr.USART_BaudRate = 9600;

USART_InitStr.USART_WordLength = USART_WordLength_8b;

USART_InitStr.USART_StopBits = USART_StopBits_1;

USART_InitStr.USART_Parity = USART_Parity_No;

USART_InitStr.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

USART_InitStr.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;

USART_Init(USART6, &USART_InitStr);

USART_Cmd(USART6, ENABLE);

I send with, USART_SendData(USART6, 0x79);

The response I read on terminal 0b1111 1001(Dec: 159)(Hx: F9)

Thanks in advanced.

Yigit

AvaTar · ‎2017-10-18

Posted on October 18, 2017 at 12:26

I guess some bits is missing, it could be stopbit but why is the stopbit missing?

Dunno, perhaps the Serial/USB converter does not support all settings.

I would check a 0xAA and 0x55 pattern, with a scope.

And I'm still not sure if the settings for your PC terminal application are correct.

TX(F407) RX(TeraTerm)

0b

01

11 1001 ------------------------------------> 0b

11

11 1001

0b

01

00 0111

------------------------------------>

0b

10

00 0111

0b

01

01 0100

----------------------------------->

0b

10

01 0100

Rather looks like a problem with the first bits.

waclawek.jan · ‎2017-10-18

Posted on October 18, 2017 at 14:27

Read out and post the RCC and UART registers content.

JW

AvaTar · ‎2017-10-18

Posted on October 18, 2017 at 13:13

Unsurprisingly, this settings seem to match those of the F407.

But what stands out, at least for me :

GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_UP;

I initialized this pins always with GPIO_PuPd_NOPULL, which worked for me.

AvaTar · ‎2017-10-18

Posted on October 18, 2017 at 13:45

I don't see an immediate problem with the clock settings.

And according to my experience, a core clock mismatch looks different.

You receive just garbage, not at all resembling the sent values.

What is suspicious - PC7 is connected to the MCLK input of the audio codec (CS43L22).

There seems no alternative route for UART6 RX - have you tried another UART ?

AvaTar · ‎2017-10-18

Posted on October 18, 2017 at 14:04

it is happen beacuse of 'HSE_VALUE' symbolic constant it was not equal to actual crystal value, how I forgot the fix it,

Can you tell us the difference between the specified and the actual value ?

The 'usual' case was 25 MHz instead of 8 MHz when using the SPL (default quartz on ST eval boards vs. ST disco boards).

And that looked >>very<< different.

Your freqencies must have been quite close.

Vangelis Fortounas · ‎2017-10-18

Posted on October 18, 2017 at 14:17

Hello!

Inside stm32f4xx.h the default HSE value is 25000000

Discovery's crystal is 8000000 Hz

Tamas Novak · ‎2017-10-19

Posted on October 19, 2017 at 10:39

Hi, the problem is with your RS232 analyzer: the oscilloscope image you attached shows a perfect 0x79.

- serial comm starts with a start bit (the first low level part before point 'a')

- then 8 bit data starting with the least sigificant bit (0x79= 0111 1001,but in order it is 10011110)

- parity bit (if enabled)

- stop bit (H level)

- idle (H level) if no immediate next byte

So the sequence you need to see (in real order) is:

0(start bit) - 10011110 (data, LSB first) - 0(parity bit) - 1(stopbit)

(you can't really see stop bit, as it is the same level as the idle following)

Check your recording, everything fine.

Tamas Novak · ‎2017-10-19

Posted on October 19, 2017 at 10:52

I mean sorry I didn't noticed that parity is disabled in your initialization code. Oscillogram shows the good 0x79 but with parity.

One more thing: a-b time is 109.9usec. Exact bit time is 104.2usec, so this 5.5% difference may corrupt communication if the receiver side also has a difference in the opposite direction.

I'd measure a longer period for higher accuracy: from the first H->L edge (start of startbit) to the last L->H (start of stopbit) it should be 9 (witohut parity) or 10 (paritiy enabled) bit times, so 937.5 or 1041.7 usec.

waclawek.jan · ‎2017-10-19

Posted on October 19, 2017 at 10:52

That would be right, but at 9216Baud, not at 9600.

The problem is in timing, i.e. in clocking of the USART, and possibly the whole mcu.

JW

Tamas Novak · ‎2017-10-19

Posted on October 19, 2017 at 11:13

Sorry Jan, I didn't check all the posts.

Anyway the whole case doesn't fit: the oscillogram seems a 9600bps comm with parity and a slighty differing clock. Its bit time is surely not shrinked or widened by 8/25x or 25/8x ratio ...

Okay, I see case is closed, gotta leave it:)))