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

Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 11, 2010
Hi,

I am using an MSP430f5438 with version 5.4 of FreeRTOS.

I am having a funny problem that I can't seem to figure out.

Basically, the slower I set configTICK_RATE_HZ (going down from 1000 all the way to 5), the faster the LED blinks... even though the call to vTaskDelayUntil( &xLastFlashTime, xFlashRate ); is such that the LED should only blink once a second no matter what the configTICK_RATE_HZ is. I stepped through and checked the xFlashRate to make sure. Its always = to the configTICK_RATE_HZ.

xFlashRate = ledFLASH_RATE_BASE;
xFlashRate /= portTICK_RATE_MS;
/* We need to initialise xLastFlashTime prior to the first call to
vTaskDelayUntil(). */
xLastFlashTime = xTaskGetTickCount();

for(;;)
{
vTaskDelayUntil( &xLastFlashTime, xFlashRate );
vParTestToggleLED( uxLED );
}


But the led blink with a period greater than 1 second when i set the tick rate to 1000 and the led blinks with a period far less than 1s when i set the tick rate to anything less than ~200

I realize more info is needed and will readily supply whatever code snippets are needed to help!!!!!!

Thanks,

Mike.

RE: Strange behavior with configTICK_RATE_HZ

Posted by Dave on February 12, 2010
Your code looks correct. Can you verify that the tick interrupt is actually executing at the expected frequency?

Where did you get the port from? I don't think its an official one.

RE: Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 12, 2010
I am going to add a bit more background:
I am using the barebones experimenter board - MSP-TS430PZ5x100
There is a single LED on the board hooked up to pin P1.0 (which is also the ACLK out if set to CLK out)
I am using the port John from westmorelandengineering.com put up on his site. I had to cut a lot of the extra stuff out as his port was for a slightly different board (same chip!). Mainly just cut out code for an LCD and such stuff.

So,

I scoped P1.0 and played with some of the various settings
- configTICK_RATE_HZ
- the led flash rate

and some other, but I soon found a very specific behaviour
If I remove the vTaskDelayUntil call, the led blinks at a fixed rate no matter what I set the RTOS tick rate to. It blinks at 400Khz
If I keep it in, the led blink rate is only affected by the xFlashRate...not the RTOS Tick rate.
So I set xFlashRate to 10, 20 , 30 , 40 (I removed the xFlashRate = ledFLASH_RATE_BASE; xFlashRate /= portTICK_RATE_MS; ).

ie, the actual rate the RTOS ticks is not being set by the configTICK_RATE_HZ.

So I am thinking its a configuration of either the Timer, or my ACLK.....


I hope this is clear!

Here is the timer and clock setup snippets.


static void InitClockSystem(void)
{
WDTCTL = WDTPW+WDTHOLD; // Stop WDT

P7SEL |= 0x03; //Set the XT1 port to Xtal functions
UCSCTL6 = XT2OFF + XCAP_2 + XT1DRIVE_3; //Set Startup mode for the Xtal

UCSCTL1 = DISMOD; // See errata UCS4
UCSCTL0 = 0x00; // Set lowest possible DCOx, MODx
UCSCTL1 = DCORSEL_6; // Select range for 8MHz operation
UCSCTL2 = 486; // Set DCO Multiplier for 8MHz
// (N + 1) * FLLRef = Fdco
// (243 + 1) * 32768 = 8MHz
UCSCTL3 = SELREF_0; // Set DCO FLL reference = XT1CLK
UCSCTL4 = SELA_0 + SELS_3 + SELM_3; // Set ACLK = XT1CLK, SMCLK & MCLK = DCOCLK

// Loop until XT1 & DCO stabilizes
while ((SFRIFG1 &OFIFG))
{
UCSCTL7 &= ~(XT1LFOFFG + DCOFFG); // Clear XT1,DCO fault flags
SFRIFG1 &= ~OFIFG; // Clear fault flags
}

UCSCTL6 &= ~(XT1DRIVE_3); // Xtal is now stable, reduce drive strength

SFRIE1 = OFIE; // Enable osc fault interrupt

// #warning "clocks are outputted to port 11" //Test purpose pins
// P11DIR |= 0x07; // ACLK, MCLK, SMCLK set out to pins
// P11SEL |= 0x07; // P11.0,1,2 for debugging purposes.
}



void prvSetupTimerInterrupt( void )
{
/* Ensure the timer is stopped. */
TA1CTL = 0;

/* Run the timer of the ACLK. */
//TACTL = TASSEL_1|CNTL_0|ID_0;// use ACLK as 32768;
TA1CTL = TASSEL1|ID0; // use ACLK as 32768;

/* Clear everything to start with. */
TA1CTL |= TACLR;

/* Set the compare match value according to the tick rate we want. */
TA1CCR0 = ( portACLK_FREQUENCY_HZ / configTICK_RATE_HZ ) - 1;

/* Enable the interrupts. */
TA1CCTL0 = CCIE;

/* Start up clean. */
TA1CTL |= TACLR;

/* Up mode. */
//TACTL |= TASSEL_1 | MC_1 | CNTL_0 | ID_0;
TA1CTL |= TASSEL1 | MC1 | ID0;




RE: Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 12, 2010
clarifying a bit:

If I keep in the vTaskDelayUntil, the led blink rate is only affected by the xFlashRate...not the RTOS Tick rate.
So I set xFlashRate to 10, 20 , 30 , 40 (I removed the xFlashRate = ledFLASH_RATE_BASE; xFlashRate /= portTICK_RATE_MS; ).

At xFlashRate = 10, the freq of the blink jumps down to 12.5Hz.... which is not 1/10th of 400KHz :P

ie, the actual RTOS Tick rate is not being set by the configTICK_RATE_HZ, rather it seems to be fixed

RE: Strange behavior with configTICK_RATE_HZ

Posted by MEdwards on February 12, 2010
“ie, the actual RTOS Tick rate is not being set by the configTICK_RATE_HZ, rather it seems to be fixed”


That is probably what the problem is then. configTICK_RATE_HZ should be used to configure the timer that generates the tick interrupt. portTICK_RATE_MS assumes this is done, so if its not then the timing is not going to work.

Is there a function called something like prvSetupTimerInterrupt() in your port.c file? That would be the normal name. Basically look at where the tick interrupt is configured to see how the frequency is set.

RE: Strange behavior with configTICK_RATE_HZ

Posted by MEdwards on February 12, 2010
Just saw you already posted the prvSetupTimerInterrupt() code, and it does seem to use configTICK_RATE_HZ. I would say you need to work out why the frequency is fixed even when you change the value, that will probably be the cause of your problem.

RE: Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 12, 2010
I just scope p11.0 .1 and .2 (ACLK, MCLK, SMCLK) and confirmed the ACLK is running at 32kHz, MCLK is 16MHz, and SMCLK is 16MHz

RE: Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 12, 2010
So, I am going to modify the Timer isr so I can verify its getting called at the right rate.

RE: Strange behavior with configTICK_RATE_HZ

Posted by Michael on February 16, 2010
So it was definitely the timer. I configured it wrong :P. The timer isr was firing at a fixed rate, which screwed up anything dependent on using the configTICK_RATE_HZ variable.


[ 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