USART ore after 8 bytes always

[michaelmccartyeng]

Posted on December 28, 2012 at 01:21

Hello All,

I'm sending data over a bluetooth device to the stm32 discovery board on usart 2. Everything is great unless I send a large amount of data (80 bytes). If I send this large amount I only end up actually getting 8 bytes and the ORE error is set. I've read up on all the other posts and tried to implement the solutions but it had no effect what so ever. I must be doing something stupid here. Why would it always stop on 8 bytes ?

/**

* @brief 

* 

* 

* @note 

* @param none

* @retval none

*/

void USART2_Config(void)

{

USART_InitTypeDef USART_InitStructure;

NVIC_InitTypeDef NVIC_InitStructure;


//Usart2_GPIO();

GPIO_InitTypeDef GPIO_InitStructure;


#ifndef STM32F10X_LD_VL

GPIO_PinRemapConfig(GPIO_Remap_USART2, ENABLE);

#
endif


RCC_APB2PeriphClockCmd( RCC_APB2Periph_GPIOA, ENABLE);

RCC_APB1PeriphClockCmd( RCC_APB1Periph_USART2, ENABLE); 


GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; 

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; 

GPIO_Init(GPIOA, &GPIO_InitStructure); 


GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; 

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; 

GPIO_Init(GPIOA, &GPIO_InitStructure); 

USART_Cmd(USART2, DISABLE);


/* Enable the USARTz Interrupt */

NVIC_InitStructure.NVIC_IRQChannel = USART2_IRQn;

NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;

NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

NVIC_Init(&NVIC_InitStructure);


USART_InitStructure.USART_BaudRate = UARTBAUD;

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


// enable this int to trigger dma ?

//USART_ITConfig(USART2, USART_IT_RXNE, ENABLE);

//USART_ITConfig(USART2, USART_IT_TXE, ENABLE);


// setup dma for usart

USART_DMACmd(USART2, USART_DMAReq_Tx | USART_DMAReq_Rx, ENABLE);


// hold onto your butts

USART_Cmd(USART2, ENABLE);

}


void USART2_IRQHandler(void)

{

u8 statusReg = 0;


statusReg = (int8_t)(USART2->SR & (uint8_t)0xFF); 
//read status


while
(statusReg & (USART_FLAG_RXNE | USART_FLAG_ORE))

{

rxByte = USART_ReceiveData(USART2);


// if we were getting data store it

if
(statusReg & USART_FLAG_RXNE)

{

cbWrite(&rxUSCBuff, &rxByte);


if
(cbIsFull(&rxUSCBuff))

{

/* Disable the USARTy Receive interrupt */

//USART_ITConfig(USART2, USART_IT_RXNE, DISABLE);

// mark buffer overflow

mygVars->status |= ERR_PKT_OF;

}

}


// read status again !

statusReg = (int8_t)(USART2->SR & (uint8_t)0xFF); 
//read status

}


if
(USART_GetITStatus(USART2, USART_IT_RXNE) != RESET)

{

USART_ClearFlag(USART2,USART_FLAG_RXNE);

}

}

[Tesla DeLorean]

Posted on December 28, 2012 at 16:54

So are you using DMA or not?

Why check and clear the RXNE at the end of the routine? Reading the DR register surely clears this automatically, and not reading the DR will cause an overrun if the next byte arrives.

[michaelmccartyeng]

Posted on December 28, 2012 at 18:49

Hey Clive, 

  Thanks for responding, I'm really at a loss. I even tried to reduce the baud to 9600 thinking that would help, its exactly the same. 

  I use dma to tx the data. I receive the data via interrupt. Its a simple polling system, no full duplex. I send out a request for data and the stm32 sends back some data via dma. I dont seem to have any issue sending the data from the stm32. Its only on receiving the data it only seems to get the first 8 bytes, then by the time i catch it in a debugger it has ore set, most times rxne is also set. 

  I'm going to test with another usb-usart module and see if i also choke after 8 bytes. Also dma RX may be a good idea, i can just int on tc and then pull the data straight out of memory. 

[michaelmccartyeng]

Posted on December 29, 2012 at 00:32

figured it out, it was in the protocol. looking in the wrong place for the problem, gets me every time. ! 

[raghavb1979]

Posted on April 17, 2013 at 06:56