Please check that the tick interrupt is actually running. You can do this by placing a break point in the tick interrupt handler, defined within port.c.
If the tick interrupt is not running then time will be standing still, so the time at which the task should unblock will never be reached.
I think you will struggle without a debugger. Maybe you could toggle a digital output from the tick interrupt.
How you enable the interrupt depends on the port you are using. It should be automatically enabled when the scheduler is started. Look at the demo application for the port you are using.
If we use:
const portTickType xDelay = 10 / portTICK_RATE_MS;
It goes further to the next code line.
But if we set the xDelay to an higher value, like 20 the program hangs at the delay…
We have tried a lot of different aproches on the delay, but they all seem to mailfunction with our processor (AT90USB1287). Even basic while/for loops are not working, if we use small loops like 1000 it doest seem to have any effect on the on / off rate of our test LED, if we make it longer the program hangs.
In your last reply you mention which port we are using. Do you mean the port our LED is on which is our output for the delay test function?
Ref port - I was referring to which RTOS port you were using. That is, which CPU and compiler. From your previous reply though I see that it is an AVR.
we loaded the .elf file in the AVR studio to debug, but stil don’t know how to check if the tick interrupt is working. in the debug it goes trew al the source like it has to but when we load the hex in the STK525 (at90usb1287) it gets stick @ the vTaskDelay.
we tried it like this now to but also that does’t work.
const portTickType xDelay = 1 / portTICK_RATE_MS;
for(int i =0; i <= 500; i++)
{
vTaskDelay(xDelay);
LEDON():
}
for(long int i =0; i <= 50000; i++)
{
vTaskDelay(xDelay);
LEDOFF():
}
