Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Tick adjustment due to critical section

Posted by lantczak on February 9, 2017

Hi,

In my system the flash erase/write action cause issue with system Tick precision. During flash writing the code is running from RAM and all interrupts are disabled. Each write operation takes ~10ms and the Tick value is not incrementing. I plan to calculate system block time based on processor cycle counter and adjust Tick value.

I want to create own function similar to vTaskStepTick() byt without configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );

In my case it can happen that Tick value is already bigger than xNextTaskUnblockTime. I’m aware that my system is not true real time system.

Question: 1) Will system work properly (tasks to unblock will run / timers will expired) with next calling of xTaskIncrementTick() if Tick value is bigger than xNextTaskUnblockTime. 2) In my understanding the only issue with this design is that task switching from block to run time will be postponed. I’m I right?

I've seen similar topic: https://sourceforge.net/p/freertos/discussion/382005/thread/edc6e9f0/ But I don't see direct answer to my questions

Best regards Lukasz


Tick adjustment due to critical section

Posted by rtel on February 9, 2017

vTaskStepTick() assumes that the tick count has not gone past the time at which a task will leave the Blocked state because of a timeout. In your case that probably won't be true. For example, if a task will timeout in 3 ticks because the block time in a call to vTaskDelay() expires (or any other blocking function), but you miss 10 ticks because of the flash write operation, then you cannot just step the tick on by 10 ticks because the task will never get unblocked.

The simplest thing to do would be to call xTaskIncrementTick() for each missed tick interrupt. The code would look something like the following, where uxMissedTicks is the number of ticks that should have occurred while the flash write was in progress.

     if( uxMissedTicks > 0U )
     {
         do
         {
             if( xTaskIncrementTick() != pdFALSE )
             {
                 xYieldPending = pdTRUE;
             }
             --uxMissedTicks;
         } while( uxMissedTicks > 0U );
     }

Tick adjustment due to critical section

Posted by lantczak on February 10, 2017

Which approach is better from system point of view : 1) The xTaskIncrementTick() loop should be called inside critical section or it is not necessary? 2) If xYieldPending is TRUE then calling of taskYIELD() should be done immediately or it is allowed to do it at the end when all uxMissedTicks are already checked

Are you sure that task is leaving the block state only when current Tick value is equal task unblock tick. I thought that it is happening when current tick is equal or greater.


Tick adjustment due to critical section

Posted by rtel on February 10, 2017

Yes it should be in a critical section - thanks for pointing that out.

It is only necessary to yield once, after exiting the loop.


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


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

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

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner