Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

dsPIC33 vTaskDelay "issue"

Posted by jandle on 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[SERPROTSTRIPPED]], 1, 1); vTaskDelay(235); // 235 ticks gives ~100ms even though tick rate is 1kHz } }


dsPIC33 vTaskDelay "issue"

Posted by woops_ on February 25, 2015

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


dsPIC33 vTaskDelay "issue"

Posted by jandle on 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.


dsPIC33 vTaskDelay "issue"

Posted by tlafleur on 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 configUSE16BIT_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"

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

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

Tom Lafleur


dsPIC33 vTaskDelay "issue"

Posted by jandle on 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.


dsPIC33 vTaskDelay "issue"

Posted by edwards3 on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists