PC received wrong data from STM32F0 usart

Question

I tried to follow the answer of this link to configure my USART of my STM32F0 Discovery board: stm32f0 uart programming

I use USART2 to send data to my PC with baudrate 9600 and 115200 both have tried.

I send characters from '0' -> '9' to PC but I received 'cg3fe2d' and some invisible characters always, there seems some regulation, can anyone help?

My STM32F0 is configured to use internal osc, 48MHz.

enter image description here

my reference code is like:

void test_uart()
{
    USART_InitTypeDef USART_InitStructure;
    GPIO_InitTypeDef GPIO_InitStructure;
    uint16_t usart_data;

    RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2,ENABLE);
    RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);

    GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_1);
    GPIO_PinAFConfig(GPIOA, GPIO_PinSource3, GPIO_AF_1);

    //Configure USART2 pins:  Rx and Tx ----------------------------
    GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_2 | GPIO_Pin_3;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    //Configure USART2 setting:       ----------------------------
    USART_InitStructure.USART_BaudRate = 9600;
    USART_InitStructure.USART_WordLength = USART_WordLength_8b;
    USART_InitStructure.USART_StopBits = USART_StopBits_1;
    USART_InitStructure.USART_Parity = USART_Parity_No;
    USART_InitStructure.USART_HardwareFlowControl =
    USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
    USART_Init(USART2, &USART_InitStructure);

    USART_Cmd(USART2,ENABLE);

    usart_data = '0';
    while(1)
    {
        while (USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);
        if (usart_data > '9')
            usart_data  = '0';
        USART_SendData(USART2, usart_data++);
    }
}

Looking at the bitstrings of the received characters vs. the transmitted characters, if the baudrate really is correct I have a suspicion your logic levels might be getting inverted one too many (or one too few) times. — Notlikethat, Feb 27 '14 at 20:25
Yeah, possibly. I am now suspecting on the OSC, may be try an out side standalone OSC. — yunfei, Feb 28 '14 at 01:38
Dear all, The problem has been resolved, I am really appreciate for your kind help, and I want to share you the result. The reason is I was using USBto232, I use 3 wires to connect it directly with the discovery board, I didnot know that RS232 is using 12V, that is the root cause. So after I use RS232 adapter, the problem resolved. Thank you all again — yunfei, Mar 15 '14 at 05:39

score 0 · Answer 1 · answered Feb 26 '14 at 13:25

0

I'd suspect it's something to do with library having a different idea about clock than you do. Especially if you get the same outputs with different baudrates.

Do you need to tell the library what your current clock is?

answered Feb 26 '14 at 13:25

domen

1,819
12
19

I think baudrate is correct with the clock, because: 1. it works, data is received with that baudrate, if I change to other baudrate, no data will be received 2. in side the usart driver, there is apbclock = RCC_ClocksStatus.PCLK_Frequency; looks the clock is automatically configured according with current PCLK – yunfei Feb 26 '14 at 13:56
You should tell "1." in original post. Are you sure the correct data is received? How? Can you maybe just make a simple echo (send what was received), and see what happens there? – domen Feb 26 '14 at 14:08
Don't assume it works because you get data! Since you copied the code above, make sure your system clock and the clock that drives the UART are valid by checking the data sheet. Double check again. In some cases not all settings are valid, and some settings can produce high rate of bit errors. Also perform the test by directly connecting to the UART port of the host machine (if you have one). This removes other factors, i.e USB-UART going bad, from the setup. – sessyargc.jp Feb 27 '14 at 01:03
To domen: Sorry I didnot mentioned '1' in original post. You are right, make echo is a good way to see the issue. I have tried to change the clock from 48MHz to 24MHz, then USART can not receive data. I plan to check with the oversampling mode register, if still not work I will make echo, and will let you know the result later. To Sessyargc.jp: I agree with you, I didnot caculate the buadrate, so I will check the baudrate and error registers' status. Thank you guys! – yunfei Feb 27 '14 at 01:57
Hello, I am still working on it, I tried different baudrate value to USART_BRR register which is to configure the baudrate divider. what I found is the calculated value for 9600 is 5000 BRR value. I tried several value around 5000, from 4996-5300, all value can have data send, and PC will receive data(even it is wrong), anyway, it will effect the data result received by PC. I guess it may be caused by the inaccuracy of internal OCS It looks – yunfei Feb 27 '14 at 15:04
Oh, I think I misunderstood you. You're assuming baudrate is correct, because some (garbage) data was received? That's completely incorrect. Some data at baudrate x might be interpreted at something else at baudrate y. An unreliable guide would be to see how much binary data was received on PC, and how much there should be, and then try to adjust baudrates. But really, you should figure out what exactly is happening with clocks, or you might hit the same issue with some other peripheral soon. – domen Feb 27 '14 at 16:20
Also, do you have access to an oscilloscope? This would be the quickest way to confirm your data baudrate. – domen Feb 27 '14 at 16:21

score 0 · Accepted Answer · answered Mar 15 '14 at 05:40

The problem has been resolved, I am really appreciate for your kind help, and I want to share you the result. The reason is I was using USBtoRS232, I use 3 wires to connect it directly with the discovery board, I didnot know that RS232 is using 12V, that is the root cause. So after I use RS232 adapter, the problem resolved. Thank you all again

PC received wrong data from STM32F0 usart

2 Answers2