LPC1768 priority assignment problem

md23ch wrote on Thursday, November 14, 2013:

Dear Users,

I am using FreeRtos 7.1.0 on LPC1768/1769 controller. I use a demo program CORTEX_LPC1768_GCC_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.0\Demo\ARM7_LPC2106_GCC\serial .

I have commented out only the end of ISR since it did not compile:
//if( xHigherPriorityTaskWoken )
// {
// portYIELD_FROM_ISR();
// }

// /* Clear the ISR in the VIC. */

I do not know if the last line VICVectAddr = serCLEAR_VIC_INTERRUPT is mandatory for the proper operation?

Best Regards


rtel wrote on Thursday, November 14, 2013:

Start by having a read through this thread:


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.


md23ch wrote on Thursday, November 14, 2013:

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 /
#define configPRIO_BITS __NVIC_PRIO_BITS
#define configPRIO_BITS 5 /
32 priority levels */

/* The lowest priority. /
#define configKERNEL_INTERRUPT_PRIORITY ( 31 << (8 - configPRIO_BITS) )
Priority 5, or 160 as only the top three bits are implemented. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( 5 << (8 - configPRIO_BITS) )

/* Priorities passed to NVIC_SetPriority() do not require shifting as the
function does the shifting itself. Note these priorities need to be equal to
or lower than configMAX_SYSCALL_INTERRUPT_PRIORITY - 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). */


And I have added two new entries:


and two functions call when doing the UARTs initialization:


Am I going in the right direction?

Best Regards


rtel wrote on Thursday, November 14, 2013:

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.


md23ch wrote on Thursday, November 14, 2013:

Thanks Richard,
Is it also important for LPC1768 (or any architecture) to use the wrapper ISR like below:

void vUART_ISR_Wrapper( void )
/* Save the context of the interrupted task. */

/* 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. */


instead of a direct call to vUART_ISR_Handler
Is it somehow related to the FreeRTOS API functions used within the ISR.

Best Regards


rtel wrote on Thursday, November 14, 2013:

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.