Can't get data from UART

[jaravena]

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

[cpmh1]

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);

[Tesla DeLorean]

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...

.

[cpmh1]

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]

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 worksDiscovery->PC worksPC->XBee worksXBee->PC worksDiscovery->XBee worksXBee->Discovery doesn'tCould 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.

[Tesla DeLorean]

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.