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:
// 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 }