2016-05-05 03:01 PM
Hi,
Set up on USART2 on STM32F4 Discovery board. Using PA2, PA3. I'm using Teraterm with a USB to serial adapter at 115200. After configuration, I send a string from the STM32F4 (''Hello\r'') which I see on the terminal window. As below... UART2_Config(); UART_PutStr(''Hello\r'') //this appears in Teraterm window while (1) { // Get a char from PC uint16_t data = USART_GetChar(); if( data == 'Q'') { //never gets here....after hitting Q on keyboard. except when stepping (see below) printf(''exiting\r''); break; } } And this is the get char function.... int16_t USART_GetChar(void) { while ( !(USART2->SR & USART_FLAG_RXNE) ); return USART_ReceiveData(USART2); } If I just let the code run, and enter Q on the keyboard, it never sees it - it's not ''getting the char''. However, if I put a breakpoint on this line: while ( !(USART2->SR & USART_FLAG_RXNE) ); the debugger stops there. I then enter a Q into Teraterm, then step the debugger, and then it seems to receive and return the character. I've tried a delay loop of microseconds to milliseconds in the while loop and it makes no difference. Instead of ''printf'', I've also tried enabling one of the Discovery LED's and just running the app without the debugger. Makes no difference. What gives here? Did I miss something obvious? Thanks for any suggestions....2016-05-05 04:09 PM
A peripheral debug view parked over the USART can break it.
2016-05-05 05:12 PM
clive1
what you are saying is the exact opposite of what I described. It works ONLY when the debugger is halted. If I flash the board, unplug the debugger and let it run, it never ''receives'' any characters. Or did I misunderstand what you are saying? Can anyone see any issues with the code? Thanks...2016-05-05 05:22 PM
Perhaps the issue isn't with the code you are showing? Broaden your focus if you can't see the problem where you're looking for it.
How about you mask the data down to 8-bit, and just echo back what you type. Get some idea what it is actually receiving.2016-05-05 06:59 PM
thanks clive1,
you've seen that it returns a uint16_t...however, I changed that from a uint8_t as I thought that might have been the problem. It made no difference. not sure if that is what you meant? there is no other code from what I've posted, other than initialization. let me ask this - when running in polling mode, as this does, should this: while ( !(USART2->SR & USART_FLAG_RXNE) ); exit on any 8-bit ascii character? In case you're wondering, I've out the initialization below....thanks void UART2_Config(void) { GPIO_InitTypeDef GPIO_InitStruct; USART_InitTypeDef USART_InitStruct; NVIC_InitTypeDef NVIC_InitStructure; //enable USART peripheral clock RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE); //enable peripheral A clock RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE); GPIO_InitStruct.GPIO_Pin = UART2_TX | UART2_RX; GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF; GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_UP; GPIO_Init(GPIOA, &GPIO_InitStruct); //set to alternate function 1 for UART operation GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_USART2); GPIO_PinAFConfig(GPIOA, GPIO_PinSource3, GPIO_AF_USART2); //set UART specific configuration properties USART_InitStruct.USART_BaudRate = UART_BAUD_RATE; USART_InitStruct.USART_WordLength = USART_WordLength_8b; USART_InitStruct.USART_StopBits = USART_StopBits_1; USART_InitStruct.USART_Parity = USART_Parity_No; USART_InitStruct.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_InitStruct.USART_Mode = USART_Mode_Tx | USART_Mode_Rx; USART_Init(USART2, &USART_InitStruct); //enable the UART USART_Cmd(USART2, ENABLE); }2016-05-05 08:08 PM
Looks reasonable, I suspect something else is going on. ie compiler, optimization, volatile, downloading, debugger...
This should work[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/USART%20example%20code%20for%20Nucleo%20F401RE&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=1932]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FUSART%20example%20code%20for%20Nucleo%20F401RE&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=19322016-05-05 08:28 PM
thank you clive1.
I will try it this code with the debugger (IAR EWARM) and stand-alone. Will let you know what happens. I forgot to mention that I have connected a scope to monitor the receive line on the Discovery board. Teraterm appears to send out the correct data, both the key that's pressed, and the '\r' (0xD)