I have FreeRTOS V7.0.1 - Copyright (C) 2011 Real Time Engineers Ltd. using the demo app as a starting point but with all of the demo code stripped out. I have the commercial version of FreeMODBUS running as one task, but it seems (will verify) unrelated. There is a second task that encapsulates the Microchip ECAN demo code.

MODBUS main task loop:
for( ;; )
{
//vTaskDelayUntil(&pxPreviousWakeTime, 10/portTICK_RATE_MS);// Period of 10 milliseconds.
// Poll the communication stack. 115200 baud --> ~100us symbol time --> ~350 us timeout
// as long as timeout is handled at RX ISR level, this can be called less often.
eMBSPoll( xMBSHdl[0] );
eMBSPoll( xMBSHdl[1] );
vTaskDelay (10/portTICK_RATE_MS);
}


When this is the only task and the vTaskDelay() is commented, it runs. Also when both it and the CAN task:

for( ;; )
{
vTaskDelay(5000/portTICK_RATE_MS);// Delay for 5 seconds.
while(C1TR01CONbits.TXREQ0==1) ;// Make sure there are no messages pending.
requestVersionInfo();
}

run, it runs for hours. The CAN task by itself also runs. I just this moment realized the CAN task also delays...

Together with CAN task and uncommenting vTaskDelay() it immediately terminates the program.

I'll keep digging, but if there's something obvious, I am missing it.

“Together with CAN task and uncommenting vTaskDelay() it immediately terminates the program. ”

Your code does not show vTaskDelay() being commented out. Do you mean "uncommenting vTaskDelayUntil"?

Do you have stack overflow checking enabled? How have you defined pxPreviousWakeTime? Have you stepped through the code to see why it is crashing?

The smallest delay you can pass to vTaskDelay() is 1 ms.
vTaskDelay(5000/portTICK_RATE_MS); // Delay for 5 seconds.
does not delay for 5 secs
I think you want
vTaskDelay(5000 * portTICK_RATE_MS); // Delay for 5 seconds.

this will make a HUGE difference.....

No, vTaskDelay(5000/portTICK_RATE_MS); is correct, although I take your point that it is probably a badly named constant. There are lots of examples uses in the FreeRTOS download.

If the tick rate is set to 1ms, then in that case, and only that case, it actually makes no difference if you multiple or divide.

WOW! I was really hoping I was contributing. :( I actually thought you were crazy, so i started searching thru the code. You are right, portTICK_RATE_MS is 1. So it doesnt matter whether you divide or multiply....
thanks!

If configTICK_RATE_HZ is set to 1000, then it is true, it does not matter if you divide or multiple - but that misses the point of the portTICK_RATE_MS constant. portTICK_RATE_MS is provided so you can change configTICK_RATE_HZ without effecting the actual time that any task blocks for. In that case, you must always divide, otherwise it won't work if you change the tick frequency (any other tick frequency will result in a portTICK_RATE_MS that is not equal to 1).

It should also be noted, that portTICK_RATE_MS only works if configTICK_RATE_HZ is less than or equal to 1000.

The HZ on the end of the configTICK_RATE_HZ name denotes that the value is specified in HZ. Hence, setting it to 1000 gives you a 1000Hz tick rate.

The MS on the end of portTICK_RATE_MS denotes that it is in MS. Hence, a tick rate of 1000Hz (1KHz) gives you a tick period of 1ms. portTICK_PERIOD_MS would be a better name.

Regards.

it turns out (a) I did not monitor this thread and thought I did so I missed the advice and (b) I was overflowing the stack... I was overflowing the stack because of some esoteric issue in dsPIC33's DMA/ECAN/ISR can of worms. I had to (turns head and coughs) POLL the DMA ready flags... sheesh.