xQueueSendBackFromISR fails after many hours

belmondo2002u wrote on Friday, February 01, 2013:

I am having an issue with xQueueSendBackFromISR. I use it inside a UART interrupt routine to send a message to another task to state that a line is ready to be read. It works for hours and suddenly for any reason, the xQueueSendBackFromISR fails. It does not return pdPASS. The queue is not full. I even reset it when the problem occur but it does not seem to help. The xQueueSendBackFromISR never seem to respond back and always fails thereafter.

Does anyone know what the issue could be ?

belmondo2002u wrote on Friday, February 01, 2013:

Here is the Interrupt Code

void USART1_IRQHandler(void)
	uint8_t ch;
	portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
	int num;
	char line[80];
	unsigned int cmd;
	static int count = 0;
	ErrorStatus err;
	// Receive interrupt
 	      err = BufferPut(&U1Rx, ch);
 		 if ( err == ERROR ) {
 			cmd = 5;
 		 else if (ch == '\n') {
 			count = 0;
 			cmd = 1;
 			num = uxQueueMessagesWaitingFromISR(uartQueue);
 			if ( xQueueSendToBackFromISR(uartQueue,&cmd,&xHigherPriorityTaskWoken) != pdPASS ) {
 				sprintf(line,"Uart Queue Send Error: %d in the queue.................",num);
 	     else if ((count == 0) && (ch == '>') ){
 	    	cmd = 2;
 	     else {
 	    	if (count >= 2000) {
 	    		cmd = 6;
 	    		count = 0;
 	    	} else {
	// Other Error Flags
		USART_ReceiveData(USART1); // Clear Error
		xprintln("Uart Error.................");

edwards3 wrote on Friday, February 01, 2013:

When it stops working can you put a break point in the code and step into the function to see what it is doing?
Is your interrupt stack large enough for the line array and to call sprintf() which often uses a lot of stack space?
Can xprintln be called from an interrupt?

richard_damon wrote on Saturday, February 02, 2013:

A couple of issues that might cause this sort of error.

1) Stack corruption, this ISR uses a LOT of stack for an ISR, since it allocates an 80 byte array. Many ports use the current tasks stack for the ISR, so in this case you need this much extra room in every task’s stack. If one doesn’t have enough, then when you get “lucky” enough to interrupt while that task is active, problems arise.

2) Make very sure that you have interrupt priorities set properly. Most ports only allow ISRs of certain priorities to call FreeRTOS APIs, and an interrupt at a higher level than this can cause corruption that could cause this.