Hello,

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}              
	FMXR    FPSCR, R0

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.

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.

Regards.

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.