USART1 interrupt issues, seems to get stuck after 2 or 3 triggers...

[wbarkley]

Posted on September 13, 2012 at 16:12The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on September 14, 2012 at 01:40

You need to stop doing the while() loops and SendString functions under interrupt, they will soak up way too much time, causing data in the in bound USART to overrun. You might also need to consider checking for, and clearing, USART errors.

Your interrupt routine should look more like this.

unsigned char rxData[4];
uint8_t rxDataCount = 0;
void USART1_IRQHandler(void)
{ 
if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)
{
rxData[rxDataCount++] = USART_ReceiveData(USART1);
if (rxDataCount >= sizeof(rxData)) rxDataCount = 0;
}
}

[wbarkley]

Posted on September 14, 2012 at 20:20 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6lX&d=%2Fa%2F0X0000000bus%2FlX9r2H2EBoeGjlYmI3q4iXJpLhVhlvpytwAyYOhI9fU&asPdf=false

[wbarkley]

Posted on September 14, 2012 at 22:07

The exact order of actual info when buffer is increased to 6 instead of 4 is:

13, 10, 51, 45, 48, 57

[Tesla DeLorean]

Posted on September 14, 2012 at 22:21

 I would also like some pointers to see if there is a better way to handle the sending of data then what I am currently doing (through interrupt, by checking certain flags, handling the tx execution differently).

You need to implement some FIFO (ring/circular) buffers, which separate the foreground function of stuffing characters/strings into the buffer, and the background (interrupt) routine which deals with the byte going to the USART.

[wbarkley]

Posted on September 17, 2012 at 14:47

Any ideals on my receive issues?

[Tesla DeLorean]

Posted on September 17, 2012 at 17:16

Any ideals on my receive issues?

Not really, I don't know the nature of the data stream you expect to be receiving. If you are expecting multiple bytes you going to have to figure out how to store and process that data, and resynchronize the stream if it starts mid sequence. 10, 13 is suggestive of a <CR> <LF> end of line markers, in which case you should design your code to parse/process lines of data, and restart when you get a new line. Also be aware that a 16-bit unsigned value is never going to be bigger than 65535, so testing for that condition isn't going to be helpful.

[wbarkley]

Posted on September 17, 2012 at 17:51

intTimes = 32 when the receive interrupt stops.  Doesn't this mean there was 32 bits received thus 4 chars worth of info - the 48, 57, 13, 10?  So why when just the buffer size increases to 6 I get values for RxBuffer[4] and RxBuffer[5] when intTimes remains at 32?  It seems as though RxBuffer[4] and RxBuffer[5] should remain at their original values since the interrupt did not execute more than 32 times.

void USART1_IRQHandler(void) {         //Receive Interrupt Handler     if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET){         intTimes++;         if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET){             RxBuffer[RxCount++] = USART_ReceiveData(USART1);             if (RxCount >= sizeof(RxBuffer)) RxCount = 0;         }     }    }

[wbarkley]

Posted on September 17, 2012 at 18:06

intTimes = 32 when the receive interrupt stops.  Doesn't this mean there was 32 bits received thus 4 chars worth of info - the 48, 57, 13, 10?  So why when just the buffer size increases to 6 I get values for RxBuffer[4] and RxBuffer[5] when intTimes remains at 32?  It seems as though RxBuffer[4] and RxBuffer[5] should remain at their original values since the interrupt did not execute more than 32 times.

[Tesla DeLorean]

Posted on September 17, 2012 at 19:09

The interrupt does not occur on a bit basis. In the case of the receive it occurs when a framed byte (start, 8 bits, stop) enters the holding buffer.

If the interrupt has occurred 32 times, you need a significantly larger buffer to hold the incoming data.