dsPIC33 vTaskDelay "issue"

jandle wrote on Wednesday, February 25, 2015:

I’ve had my system working with FreeRTOS V7.0.1 for several years. I have had vTaskDelay working as expected throughout the program. Suddenly today I am trying to pad the time in a loop to get a 90ms net delay (minimum).

usTempInterSensorRetry causes a measurement to be made while enforcing 10ms activity and 90ms passive state segments until completion. A 50-60ms vTaskDelay should flesh out the needed 90ms gap. Instead the loop timing is more or less constant until over 150 ticks (ms) delay. A number of 235 seems to give ~90-100ms and it is monotonic after that.

Originally I was calculating the needed delay:

            // adjust this number to maintain duty cycle
            usDelay = 100 - g_usFCC_Duty;
            usDelay = usDelay > 50? usDelay: 50;
            usDelay -= 40; // adjustment for what naturally happens

            //if (g_usFCCMode) // comment if() so I can debug outside other limits
            vTaskDelay (usDelay/portTICK_RATE_MS);

but after a very frustrating day I threw in fixed constants. I can understand how a delay could be be LONGER - the delay is how long tasks are kept OFF the run list after which normal latency determines the additional time.

To make matters worse, even the code with a fixed delay acts like the delay is 0 every 2 seconds or so, so on an oscilloscope the signal activity is 10ms/90ms for 15 - 25 cycles (1.5 to 2.5 seconds) with an occasional missing gap.

I am sure it is something stupidly trivial, but I am out of ideas and time simultaneously. Tomorrow I will test tick count before and after the call. I already verified that xTickCount is only modified where it should be. I can solder a wire and toggle a scope trace before and after the delay. These will all decide if it is HW timing or SW hiccups, but are there any better ideas? I’ll also test a release build without the RealICE debugger, but I was debugging because the obvious code was not working as expected.

The simplified code is:

while(1)
{
// commenting this line proves it is only source of signals
usTempInterSensorRetry(&cAutoCmdBuf[MSID0BYTE[SER_PROT_STRIPPED]], 1, 1);
vTaskDelay(235); // 235 ticks gives ~100ms even though tick rate is 1kHz }
}

woops_ wrote on Wednesday, February 25, 2015:

THis is 16 bits part, yes? Could you get under/over flow? What is the delay variable inside vTaskDelay?

jandle wrote on Wednesday, February 25, 2015:

16 bit processor so if task scheduler does no handle wrap around it could glitch every 65.5 seconds. That has crossed my mind, but every single call at this location is causing the issue. Intended value is <100 ticks (ms). I have to use 235 to get a real 90ms.

Almost through the brush fires to where I can really test again with scope and so forth. Same behavior free running release code and using RealICE physical debugger on target.

tlafleur wrote on Wednesday, February 25, 2015:

I use FreeRTOS 8.2 with dsPIC33EP and dsPIC33FJ, I have many delays of
over 10 minutes without any issues…
I use RealICE with no issues…
I use timer 1 as the TICK at 1ms
Timer 4 running at 20KHz for FreeRTOS stats

check:

#define configUSE_16_BIT_TICKS 0

If its zero, you are using 32bit ticks, if 1, then 16bit ticks…
at 1ms, * 16bits = 65.535 sec, at 32bits = 4,294,967.296 sec or 49.71 days

On Wed, Feb 25, 2015 at 8:26 AM, Jeff Andle jandle@users.sf.net wrote:

16 bit processor so if task scheduler does no handle wrap around it could
glitch every 65.5 seconds. That has crossed my mind, but every single call
at this location is causing the issue. Intended value is <100 ticks (ms). I
have to use 235 to get a real 90ms.

Almost through the brush fires to where I can really test again with scope
and so forth. Same behavior free running release code and using RealICE
physical debugger on target.

dsPIC33 vTaskDelay “issue”
https://sourceforge.net/p/freertos/discussion/382005/thread/f9754f06/?limit=25#a86c

Sent from sourceforge.net because you indicated interest in
SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

~~ _/) _/) _/) ``` _/) ~~

Tom Lafleur

jandle wrote on Wednesday, February 25, 2015:

PEBKAC - problem exists between keyboard and chair

The function in my loop was exiting on a timeout. The changes I was making supported a hardware duty cycle limit. The reduced duty cycle caused measurements to take longer. They were timing out, but the HW kept running (different chip). I was looking at the HW output to diagnose the operation and only if the delay exceeds the amount by which HW exceeds timeout does the delay have any effect.

edwards3 wrote on Wednesday, February 25, 2015:

16 bit processor so if task scheduler does no handle wrap

Sounds like you have found the cause of your problem, but for future reference the scheduler does handle wrap arounds in block times and tick count. It does this in a very neat way using an overflow list that gets switched to be the real list when the tick count overflows.