Quality RTOS & Embedded Software

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


CCS6 Port of Cortex R4F seems to use more stack than allocated

Posted by westmorelandeng on March 23, 2015


I am working on a variant of the Cortex R4F port that is part of the distribution using the CCS tools.

When debugging under IAR - I have noticed a few things:

in portASM.s (or portASM.asm) - when the FPU (registers) stack (are)is being restored: in portRESTORE_CONTEXT macro:

        LDMFD   LR!, {R0}
	FLDMIAD	LR!, {D0-D15}              

this appears to end up pointing LR 128 bytes beyond where it is when not running with the FPU so that when LDMFD LR, {R0-R14}^

gets executed it is pointing to the wrong place. Since the minimal stack size is 128 bytes that has to change to even have a chance at getting it to work.

Also; once in this mode; how does ulFPUContextConst ever get reset? It appears that once it is set it isn't unset - meaning; running a task that requires the FPU enables that variable and every task that runs after that does the FPU context save/restore; which results in a stack overflow.

This is what I am seeing in the IAR EWARM debug environment when enabling the FLOP demo code and flop_hercules.c.

Thanks, John W.

CCS6 Port of Cortex R4F seems to use more stack than allocated

Posted by rtel on March 24, 2015

I was having an [email] conversation with somebody have an issue with code generated by HALCoGen the other day. I was looking for it in the forum but can't find it - so maybe it was via private email. Anyway the conclusion was that the HALCoGen code port was different to the port in the FreeRTOS download as it appears to be using the MPU.


CCS6 Port of Cortex R4F seems to use more stack than allocated

Posted by westmorelandeng on March 24, 2015

I think it is possible to add the latest kernel files to HALCoGen since there are underlying directories. I am a little surprised TI isn't working with you on this.
But, the issue from there is how the port is handled. I might try to see how hard it is to get a simple blinky demo going using the tool with the latest kernel files and not enabling any peripherals that aren't being used. I think you may be able to build a demo then but the initialization of the processor; especially with Hercules; is an issue. Just using the raw output from HALCoGen isn't going to be successful if you don't know how to navigate how the processor gets initialized and if the linker includes a cstartup.o or _lowlevel_init.o or something similar that undoes some init code you thought was working.

It appears it generates correct code for the VIM but you have to make sure your vectors and irqs are correct. IAR has changed their syntax recently regarding IRQ's and some pragmas so the tool needs to keep up with that.

But, I think HALCoGen has a future as long as it is updated.

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

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

Latest News

Version 10.1.0 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.


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


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