I have retargeted the LPC2106 GCC demo for my LPC2138 MCU based on the Rowley 2138 demo.
Everything seems to work fine except for vTaskDelay and vTaskDelayUntil. It seems that whenever I call any of these it just stucks there forever. I have not disabled the interrupts. Unfortunately I don’t have access to a debugger, so I am only relying on LEDs for now. I enable a LED then call vTaskDelay or vTaskDelayUntil, then it will never reach the code part to disable the LED. Do you have any idea what can cause such behavior?
By the way if I replace vTaskDelay with an own crappy delay function (like counting to 0xFFFFF) the code works as expected.
I understand what you mean. But how does it work for 2106 then? It uses the same GCC/ARM7_LPC2000/port.c as my project, and it does not define these interrupt handlers in its FreeRTOSconfig.h you mention on the FAQ page. Since I don’t have an LPC2106 I have not tried that demo without modification, but I can see it uses vTaskDelay, and it works.
Anyways I will try that and see if it works. Thanks!
Sorry - my mistake - you are correct that the page I directed you to is relevant only to microcontrollers with Cortex-M cores, whereas you are using an ARM7 core.
The 2106 needs vPortYieldProcessor() to be installed on the SWI interrupt vector to manage taskYIELD() calls, and the IRQ vector to autovector to the correct interrupt for timer ticks. On the 2106 that is done using a vector table something like the following in the startup code (assuming you have not changed the timer configuration in the 2106 port layer):
Thank you Richard. I think the problem was with the serialISR routines. When I rewrote it to use UART1 instead of UART0 I must have missed something and probably it kept the whole MCU blocked before the scheduler could even start.
I started everything again from the LPC2106 example and everything works correctly now.