OS hangs in portTASK_FUNCTION

Since I have setup the uart2 to generate an Rx interrupt above kernel priority, it happens randomly that the OS gets in a continues loop within the: static portTASK_FUNCTION( prvIdleTask, pvParameters ) It just keeps running that function over and over again. And no other task will get executed anymore. It usually happens when the Rx buffer has overflowed. However, in the same interrupt, before i get the data, I check if an overflow has occurred. And if it does, i just discard the the data and clear the overflow stat bit. The most of the UART code is based on the example supplied in the demo. I do not set/read any variable during the interrupt. I only send a queue using the correct interrupt routine provided for it. I notice that the error occurs much less when i remove the following function: portEND_SWITCHING_ISR( xHigherPriorityTaskWoken ); Does anyone knows what this could be?

OS hangs in portTASK_FUNCTION

You don’t say which port you are using. Not all the ports allow interrupt nesting, so that might be what the problem is. The idle task is meant to sit in a loop if there are no other tasks that can run so the problem seems to be that none of your other tasks are wanting to do anything.

OS hangs in portTASK_FUNCTION

Interrupts above kernel priority are not allowed to call freeRTOS routines, so I suspect you are corrupting some system data. When freeRTOS is manipulating critical data, is enters a critical section which disables interrupts of kernel level and below so nothing else will try and adjust the data area while it is being updated. If an interrupt above kernel level calls an RTOS routine, it may manipulate that area that is in the middle of being manipulated and mess it up.

OS hangs in portTASK_FUNCTION

Please Richard Barry, can you comment on this, because from what I understand: 1) IRQ are suposed to be above kernel piority 2) it is safe to call from ISR functions named fromISR

OS hangs in portTASK_FUNCTION

It if fine to call any API function that ends in "FromISR" from within an ISR – but no others. I cannot answer point 1) because I don’t know which port you are using. Regards.

OS hangs in portTASK_FUNCTION

Richard, Your documentation says that for ports that support configMAX_SYSCALL_INTERRUPT_PRIORITY, then that is the highest level interrupt that can call the FromISR routines, and that those ports support not disabling all interrupts when in a critical section.

OS hangs in portTASK_FUNCTION

That is correct.  Interrupts at priority level configMAX_SYSCALL_INTERRUPT_PRIORITY and below can call API functions that end in "FromISR".  Interrupts that are above that priority cannot call any API functions.  API functions that do not end if "FromISR" must not be called from any interrupts. Sorry if I’m not being clear – its been a long day. Its difficult to answer definitively without knowing the port being used. Regards.

OS hangs in portTASK_FUNCTION

First of all, thanks for the real fast reply’s you guys! I really like it. I`m using the PIC32 port where interrupt nesting is possible. I’ve the interrupt priority set at configKERNEL_INTERRUPT_PRIORITY + 1 : ConfigIntUART2( ( configKERNEL_INTERRUPT_PRIORITY + 1 ) | UART_INT_SUB_PR0 | UART_RX_INT_EN | UART_TX_INT_EN  ); In the RtOS config I’ve set the following: #define configKERNEL_INTERRUPT_PRIORITY            0x01 #define configMAX_SYSCALL_INTERRUPT_PRIORITY    0x03 And these are the only function call’s that are used in the interrupt: cChar = ReadUART2(); // used to get the data from the Rx buffer xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken ); mU2RXClearIntFlag(); The first and last functions are predefined by microchip. Hope you can help me out.

OS hangs in portTASK_FUNCTION

Looks like I made an error myself. Yesterday, MPLab crashed. And when i reopened the program it opens the last opened project as usual. At the moment I have to almost similar devices and code, so i didn’t see that MPLab opened the other project instead of the correct one. And i forgot to check it. And just programmed it. So the problems above are not that strange, since it was for another device. Sorry guys! However, with the correct code, there was almost the same error. And it happened too when i integrated the  uart2 Rx interrupt. But that didn’t come so frequently as with the wrong code I used above (so that’s had me wondering today that it just might be the wrong code ;) ). For the moment, I just discovered one error with might be just it. With the demo code supplied with the OS, errors from the UART are not monitored (like, overflow/parity/framing error). So when one of the errors occurs, the UART-error interrupt flag get set. This will cause that no other Rx interrupts will happen anymore until this flag, including the [ OERR: Receive Buffer Overrun Error Status bit ] get cleared.

OS hangs in portTASK_FUNCTION

There is nothing obviously wrong there, assuming ReadUART2() returns immediately with the register data and does not attempt to poll until data is available. Are you defining the interrupt with the asm wrapper as per the example in the FreeRTOS download? Regards.

OS hangs in portTASK_FUNCTION

Richard, Indeed I`m using the interrupt wrapper from the example. Still the problem does exist. The OS doesn’t run anymore any task. Looks like it will randomly stall in a task after some interrupts happened from the UART2 (even when there is no error with the UART, i checked the SFR’s), it just keeps running and running and no switch to another task will happen anymore. So I`m still looking for an error in the UART2 interrupt. My next move is to be sure that the microchip supplied functions like ReadUART2();   do not stall to wait for data.

OS hangs in portTASK_FUNCTION

Have you tried running with stack checking turned on? Set configCHECK_FOR_STACK_OVERFLOW to 2 in FreeRTOSConfig.h Define a function like void vApplicationStackOverflowHook( void ) {     while(1); }

OS hangs in portTASK_FUNCTION

Richard, Indeed I`m using the interrupt wrapper from the example. Still the problem does exist. The OS doesn’t run anymore any task. Looks like it will randomly stall in a task after some interrupts happened from the UART2 (even when there is no error with the UART, i checked the SFR’s), it just keeps running and running and no switch to another task will happen anymore. So I`m still looking for an error in the UART2 interrupt. My next move is to be sure that the microchip supplied functions like ReadUART2();   do not stall to wait for data.

OS hangs in portTASK_FUNCTION

Dave, Yes, I’m using the stackOverflowhook. I’ve placed the function in the main.c like this: void vApplicationStackOverflowHook( xTaskHandle *pxTask, signed portCHAR *pcTaskName ) { while(1); } And on top I’ve placed the prototype (don’t know if that is necc.): void vApplicationStackOverflowHook( xTaskHandle *pxTask, signed portCHAR *pcTaskName ); I placed a breakpoint on the while loop, but it never gets there. Even if i minimize the stack below an acceptable value. PS. I don’t know why my message was posted 2 times, sorry!