LPC1768 priority assignment problem

Dear Users, I am using FreeRtos 7.1.0 on LPC1768/1769 controller. I use a demo program CORTEXLPC1768GCC_RedSuite with some modifications. I have added few new tasks among them two which deal respectively with UART1 and UART2. These tasks coup with ISRs to send and to get data in/out from UARTs. After let say 3 – 4 hours of operation the systems comes to the endless operation in the: list.c vListInsert function. According to the suggestion in the list.c file I have extended the stack size for all tasks but it did not help. I suspect that the problem could be due to the priority assignment. I have set all task to the priority 3 as shown below: Page will refresh every 2 seconds. Task State Priority Stack #
uIP R 3 366 0 IDLE R 0 106 4 RC5 B 3 126 3 RX1 Input B 3 288 7 SHT75 B 3 104 1 Input B 3 102 2 RX2 Input B 3 240 6 Tmr Svc B 1 118 5 Refresh count = 288 The ISRs which deal with UART1 and UART2 are base on the xQueueSendFromISR and xQueueReceiveFromISR functions. Actually I use the code for UART1 and UART2 which was done for C:FreeRTOSV7.1.0DemoARM7LPC2106GCCserial . I have commented out only the end of ISR since it did not compile: //if( xHigherPriorityTaskWoken ) // { // portYIELDFROMISR(); // } // /* Clear the ISR in the VIC. */ // VICVectAddr = serCLEAR_VIC_INTERRUPT; I do not know if the last line VICVectAddr = serCLEARVICINTERRUPT is mandatory for the proper operation? Best Regards Mike

LPC1768 priority assignment problem

Start by having a read through this thread: https://sourceforge.net/p/freertos/discussion/382005/thread/48e7b6ad/ You are using a Cortex-M3, but copying a serial implementation from an ARM7 that has completely different IP – that is not going to help. For example, there is no VICVectAddr on the LPC1768 so clearing it is definitely not mandatory. Regards.

LPC1768 priority assignment problem

Hi Rechard, Thank you very much for your replay and your suggestion. I understand that the best way would be to use DMA when dealing with UARTs but I do not have an experience with that yet. Actually when configuring and initializing the UARTs I did not set the Interrupt priorities for UARTs. Do you think that it might cause the problem which I am facing now? I have examined the freeRTOSConfig.h : : /* Use the system definition, if there is one */

ifdef __NVICPRIOBITS

#define configPRIO_BITS       __NVIC_PRIO_BITS

else

#define configPRIO_BITS       5        /* 32 priority levels */

endif

/* The lowest priority. */

define configKERNELINTERRUPTPRIORITY ( 31 << (8 – configPRIO_BITS) )

/* Priority 5, or 160 as only the top three bits are implemented. */

define configMAXSYSCALLINTERRUPTPRIORITY ( 5 << (8 – configPRIOBITS) )

/* Priorities passed to NVICSetPriority() do not require shifting as the function does the shifting itself. Note these priorities need to be equal to or lower than configMAXSYSCALLINTERRUPTPRIORITY – therefore the numeric value needs to be equal to or greater than 5 (on the Cortex-M3 the lower the numeric value the higher the interrupt priority). */

define configEMACINTERRUPTPRIORITY 5

define configUSBINTERRUPTPRIORITY 6

: : : And I have added two new entries:

define configUART1INTERRUPTPRIORITY 7

define configUART2INTERRUPTPRIORITY 8

and two functions call when doing the UARTs initialization: NVICSetPriority( UART1IRQn, configUART1INTERRUPTPRIORITY ); NVICSetPriority( UART2IRQn, configUART2INTERRUPTPRIORITY ); Am I going in the right direction? Best Regards Mike

LPC1768 priority assignment problem

Actually when configuring and initializing the UARTs I did not set the Interrupt priorities for UARTs.
You absolutely must set the priority if you are using FreeRTOS API functions in the ISRs. The documentation is very clear on this I think.
Am I going in the right direction?
Looks ok to me. Regards.

LPC1768 priority assignment problem

Thanks Richard, Is it also important for LPC1768 (or any architecture) to use the wrapper ISR like below: void vUARTISRWrapper( void ) { /* Save the context of the interrupted task. */ portSAVE_CONTEXT();
/* Call the handler.  This must be a separate function from the wrapper
to ensure the correct stack frame is set up. */
__asm volatile ("bl vUART_ISR_Handler");

/* Restore the context of whichever task is going to run next. */
portRESTORE_CONTEXT();
} instead of a direct call to vUARTISRHandler Is it somehow related to the FreeRTOS API functions used within the ISR. Best Regards Maik

LPC1768 priority assignment problem

No, that is completely wrong. Please use the quick start guide to learn how to find a documentation page for your port – that will tell you how to do what you are trying to do. I’m not going to replicate the information here as it is already provided for you to read. Regards.