cancel
Showing results for 
Search instead for 
Did you mean: 

Can't get data from UART

jaravena
Associate
Posted on September 10, 2014 at 00:13

I'm trying to get data from the usart by waiting for RXNE to get set, but somehow it doesn't ever happen, and it gets stuck forever waiting. An equivalent program on PC communicates just fine with the same endpoint so it shouldn't be that, it's probably a dumb error on my part, I'm posting some sections of my code in case someone can spot anything iffy:

    GPIO_InitTypeDef GPIO_init_struct;

    USART_InitTypeDef USART_init_struct;

    char rbyte;

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART6, ENABLE);

    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE);

    GPIO_StructInit(&GPIO_init_struct);

    GPIO_init_struct.GPIO_Pin   = GPIO_Pin_6 | GPIO_Pin_7;

    GPIO_init_struct.GPIO_Mode  = GPIO_Mode_AF;

    GPIO_init_struct.GPIO_Speed = GPIO_Speed_50MHz;

    GPIO_init_struct.GPIO_OType = GPIO_OType_PP;

    GPIO_init_struct.GPIO_PuPd  = GPIO_PuPd_UP;

    GPIO_Init(GPIOC, &GPIO_init_struct);

    GPIO_PinAFConfig(GPIOC, GPIO_PinSource6, GPIO_AF_USART6);

    GPIO_PinAFConfig(GPIOC, GPIO_PinSource7, GPIO_AF_USART6);

    USART_StructInit(&USART_init_struct);

    USART_init_struct.USART_BaudRate            = 9600;

    USART_init_struct.USART_WordLength          = USART_WordLength_8b;

    USART_init_struct.USART_StopBits            = USART_StopBits_1;

    USART_init_struct.USART_Parity              = USART_Parity_No;

    USART_init_struct.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

    USART_init_struct.USART_Mode                = USART_Mode_Rx | USART_Mode_Tx;

    USART_Init(USART6, &USART_init_struct);

    USART_Cmd(USART6, ENABLE);

    while(USART_GetFlagStatus(USART6, USART_FLAG_RXNE) == RESET);;;

    rbyte = USART_ReceiveData(USART6);

By the way, I'm using a stm32f4 discovery board, with the StdPeriph 1.3.0 library and GNU Tools for ARM Embedded Processors.

#stm32 #uart #usart #receive
5 REPLIES 5
cpmh1
Associate II
Posted on September 10, 2014 at 00:59

Doubt this will helpe, but depending on the compiler flags, etc. the call the function in the loop might be inlined and the loop optimized out.   I would suggest using a loop more like

volatile int stat;

do

{

  stat =

USART_GetFlagStatus(USART6, USART_FLAG_RXNE);

}

while(stat == RESET);

Posted on September 10, 2014 at 02:18

Well I seriously doubt it's optimizing a function call out, I would look at exactly how the USART is connected externally (it's CMOS not RS232 levels), and if the HSE_VALUE and clock settings were correct for the board in question.

I posted a USART6 PC6/7 example for the STM32F4DIS-BB board, about half way down

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/%5bSTM32F4-Discovery%5d%20USART6%20Problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=2...

.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
cpmh1
Associate II
Posted on September 11, 2014 at 01:58

yeah, I doubt the function optimized out too, *but* in a project I was on that started using gcc 4.7, we found that ''volatile'' was being ignored (not a bug, as a compiler policy!) and it broke the app.  with all the inlining and execution reordering being done in newer compilers I wouldn't be surprised to find out the function is only called once.

One other thing I've run into is that the host driver is not sending chars because *it* expects DSR/RTS/etc..  Just because you turn off h/w handshaking on your side doesn't mean it's off on the other side.  Most people just use the 3 wire Rx/Tx/Gnd solution forgetting to tie the modem control lines in the cable. 

jaravena
Associate
Posted on September 11, 2014 at 16:13

Thanks, your post gave me the idea of testing the communication between PC and the MCU and it turns out it's working ok, but somehow I cannot listen to the XBee (and yet I can send data to it and it works, I can tell because the Xbee actually transmits).

PC->Discovery works

Discovery->PC works

PC->XBee works

XBee->PC works

Discovery->XBee works

XBee->Discovery doesn't

Could it be related to the clock, as you were saying? I really don't know much about how the clocks works, I've been reading the MCU's manual but still don't quite understand it.

Posted on September 11, 2014 at 16:34

The clock settings normally reside in system_stm32f4xx.c and are initialized via SystemInit()

The key take away is that DISCO boards have 8 MHz clocks, and EVAL boards have 25 MHz clocks, so the PLL settings must be coherent with this, and the value of HSE_VALUE should reflect the clock supplied.

One could use a scope to check the bit timing of a stream of data.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..