Quality RTOS & Embedded Software

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




Loading

vTaskIncrementTick changed to xTaskIncrementTick

Posted by westmorelandeng on October 24, 2013

Hello Richard and FreeRTOS'ers,

I see that vTaskIncrementTick was changed to xTaskIncrementTick - was just trying to help with a port and 'upgraded' from 7.4.0 to 7.5.3 - I searched this forum didn't see any mention of it.

Regards, John Westmoreland


vTaskIncrementTick changed to xTaskIncrementTick

Posted by westmorelandeng on October 24, 2013

Richard,

I have had an inquiry regarding the port for the '430 for one of the parts with larger memory - the '6659 which also has a non-contiguous SRAM memory space. I had a port for the '5635 and modified it to run in the simulator (I can't get that part from TI just yet) - upgraded to 7.5.3 and it is running in the IAR v5.60.2 simulator as the '6659. Note I had to fix the linker map file.

The port ran OK when I had 13KB allocated. I just tried to allocate 30KB and I am getting a stack overflow message even though with the current linker file I have allocated 0xBFFF bytes which is 49K.

Hmmm, I will look into this further.

Regards, John


vTaskIncrementTick changed to xTaskIncrementTick

Posted by westmorelandeng on October 24, 2013

Richard,

I turned off stack checking:

define configCHECKFORSTACK_OVERFLOW 0

set this:

define configTOTALHEAPSIZE ( ( size_t ) ( 30 * 1024 ) )

and the port is running.

I put the linker control file back to 'normal'. In this port, however, I am allocating almost all memory on the RTOS's heap. All arrays, including 2 dimensional, are all being allocated on the RTOS heap.

So, it may appear there is an issue with the stack overflow checking method.

I will try to get my hands on a real part in the mean time.

Regards, John


vTaskIncrementTick changed to xTaskIncrementTick

Posted by westmorelandeng on October 24, 2013

Richard,

And, when I do this:

define configTOTALHEAPSIZE ( ( size_t ) ( 32 * 1024 ) )

The IAR linker throws this:

Error[e16]: Segment DATA20Z (size: 0xffff830d align: 0x1) is too long for segment definition. At least 0xfffec30d more bytes needed. The problem occurred while processing the segment placement command
"-Z(DATA)DATA20I,DATA20Z,DATA20N,DATA20HEAP+DATA20HEAPSIZE=2400-63FF,F0000-FBFFF", where at the moment of placement the available memory ranges were "CODE:2504-6305,CODE:f0000-fbfff" Reserved ranges relevant to this placement: 2400-6305 DATA20I 6306-63ff CSTACK f0000-fbfff DATA20I Error while running Linker

The segment size is obviously incorrect.

Regards, John


vTaskIncrementTick changed to xTaskIncrementTick

Posted by richardbarry on October 24, 2013

I see that vTaskIncrementTick was changed to xTaskIncrementTick - was just trying to help with a port and 'upgraded' from 7.4.0 to 7.5.3 - I searched this forum didn't see any mention of it.

The change was made to all ports in V7.5.0. Search for "Compatibility information for FreeRTOS port writers:" in http://www.FreeRTOS.org/History.txt. It is a major performance enhancement for ports that can make use of it. A context switch should only be performed if xTaskIncrementTick() returns pdTRUE.

So, it may appear there is an issue with the stack overflow checking method.

It is known that some architectures that have segmented memory have a problem with stack overflow checking (x86 for example), but I've just checked the MSP430X demo and, in the demo at least, it is turned on. Maybe there is an issue when it goes above 0xffff (max 16-bit value)? That would seem to be borne out by your other posts as it appears the linker pukes if you try creating an array over that size.

Regards.


vTaskIncrementTick changed to xTaskIncrementTick

Posted by jdurand on October 24, 2013

Have the main documentation files been updated? I just searched my PDF file and no version of TaskIncrementTick appears in it. Of course this means the changes doesn't bother me as I didn't know it existed in the first place. I imagine there's other additions I'm not aware of (change history files aren't the most interesting to browse and I can't add them to the PDF where I could later find them when needed). Anyone starting off using the documentation is certainly not going to read the change history.

I have "FreeRTOS Reverence Manual" v 1.2.1 (2011), "Using the FreeRTOS..." from 2010 (and one of the paper books).


vTaskIncrementTick changed to xTaskIncrementTick

Posted by richardbarry on October 24, 2013

xTaskIncrementTick() is an internal function, not an API function, hence you won't find it documented in the reference manual. In the change history it is under info "for FreeRTOS port writers" rather than "FreeRTOS application writers".

Regards.


vTaskIncrementTick changed to xTaskIncrementTick

Posted by westmorelandeng on November 4, 2013

Richard - I am going to start another related thread - there is an issue with devices that use RAM > 0xffff evidently.

Thanks, John


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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