Compilation of FreeRTOS fails

I have now integrated FreeRTOS in the NIOS 2 ecosystem provided by Intel, based on Eclipse (Mars), but the compilation faild with strange errors.
The port I used is based on FreeRTOS 7. I personally have FreeRTOS 8 somewhere hanging around but I tried the current version.
Is this a problem?
I tried to find V7 on the web page, but no chance.
My error? BaseType_t is undefined …

Thanks for helping.

With best regards


Is BaseType_t defined for the FreeRTOS port you are using? It should be defined in the portmacro.h: FreeRTOS-Kernel/portmacro.h at main · FreeRTOS/FreeRTOS-Kernel · GitHub


Hi Gustav,
want to post a reply to myself and now found your reply.
You were right, in my portmacro.h which I get, this definitions were absent.

Ok, not a big deal for now, youst copied it in and, lot better.

But I have another strange problem. I hope I can insert a screen shot here.

There is a line ‘#define portBASE_TYPE long’ and I get the error ‘Missing binary operator before token long’.
I am not that C language guru, but I can’t find any strange syntax in this line.
Two lines above there is a similar definithion, no error.
This lines were originally and untouched, but maybe, the guy making the port did something special.

Is there any explaination, why the typedefs for BaseType_t were missing? Is this a versioning problem?
Where there other files affacted?

Thanks for helping!!!

I try to upload the screenshot now, you will see if I am successful or not.

With best regards


Is there any explaination, why the typedefs for BaseType_t were missing? Is this a versioning problem?
Where there other files affacted?

That depends on where you got those port files from.

There is a line ‘#define portBASE_TYPE long’ and I get the error ‘Missing binary operator before token long’.

Can you paste the complete error log?


Hi Gustav,

I get the a port from and another one from a company (about 8 years old). I first struggle to integrate it into the Eclipse environment I get from Intel for the NIOS 2 processor. The port from is for older and now incompatible tool chain, the other example fits better and so I am able to do integration.
I also will shar this work if I am successful.

Here my experiments. I changed ‘long’ to the type ‘alt_32’, this is the type the software from intel is using, same problem. I restarted Eclipse, same problem, I moved the line elswhere, same problem.
I getting frustrated now.

Thanks a lot for helping!!!

Seems like the error is in the compilation unit alt_env_lock.c. Can you share the content of that?


Hmmm, new user were not allowed to upload attachments …
I only can send screen shots, sorry for that.

Thanks a lot for helping.


Here the error with more details

Thanks for helping


So the problem is in the expansion of configMAX_PRIORITIES. What is OS_MAX_PRIORITIES in FreeRTOSConfig.h?


Hi Gaurav,
ok, there is a config tool provided by Intel, and this value should be 5.

But maybe something fails. I will try to find out, how this ‘5’ ends up in OS_MAX_PRIORITIES, but now I went to bed. It is 0:05 here … sorry.

Thanks a lot for helping me. Hope I can find out something.

I will start with setting the values manually, and than we will see whats going on quickly.

Good night


If you grep/search for ‘OS_MAX_PRIORITIES’ you should see a #define somewhere.


I think the preprocessor is choking on this:

#if configMAX_PRIORITIES < 1

because configMAX_PRIORITIES is type cast. The preprocessor’s expression evaluator wants simple numeric literals only, like 5 or even 5UL etc., but not (int) 5 or the like.

In FreeRTOSConfig.h, you will probably have to change configMAX_PRIORITIES to:


assuming as Gaurav mentioned that the #define for OS_MAX_PRIORITIES is a simple numeric literal.

Not read the whole thread - but V7 to v8 was a major upgrade. See Upgrading to FreeRTOS V8

Hi Jeff,
I easily found the definition which comes from the config tool:


looks quite normal to me.

Here the line in FreeRTOSConfig.h:

#define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) OS_MAX_PRIORITIES )

Ok, I am not a C language guru but I learned that better but paranthesis around everything, the tools (preprocessor) arn’t that good. I will try.

Doesn’t help, sorry:

So, here the new line:

#define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) ( OS_MAX_PRIORITIES ) )

But omitting the cast do the job:


works now. Ok, is this a solution or only a hack? I think, the guy who put in the cast knows why.

Hi Richard,
ok, will check this in the meantime maybe some troubles can be solved this way.

Now I get other errors (business as usual), but it is just a missing file. Maybe the versioning issue, I think I can solve this easily.

And give new errors a chance …

Thanks all for helping.


Hi all together,

the file stack_macros.h were missing, because it appears at a later version than the port/example was made.
There is a script to provide to the Eclipse eco system which runs when the BSP (board support package) which infact is a softcore support package is prepared.

During this process, all files from a list were copied from a folder called ‘components’ to the project folder for use with the app.
So you can made changes to the files in the IDE, but after generating a new BSP … but ok, is as is.

After extending this script and copying stack_macros.h I get a correct setup and …

… it compiles !!!

So, I have a syntactically correct FreeRTOS distribution, now lets see if it is semantical correct too.

Open questions for now:

How should I deal with the cast problems in FreeRTOSConfig.h, or is this a file I have to alter to fullfill my compilers needs? (And I don’t mean only the numbers used here).

Thanks all for helping so far. I hope the port.c file and some other points arn’t that bad.

With best regards


Hi all,

here another ‘problem’, maybe caused by versioning:

void vPortSysTickHandler( void )
	// only make ticks if the scheduler has been started.
	if ( xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED )
		// Increment the Kernel Tick.

		// If using preemption, also force a context switch.
#if configUSE_PREEMPTION == 1

‘vTaskIncrementTick();’ is not known (any more), and the compiler ask me, if I want to use ‘xTaskIncrementTick();’ instead.

Should I?

With best regards


It’s probably a solution, not a hack. You could go look at all the uses of configMAX_PRIORITIES to determine the impact of the casting, but it’s probably not important for this particular symbol.

Yes, you can “upgrade” to xTaskIncrementTick() and then use its return value to conditionally call vTaskSwitchContext().

And be sure to look over the link Richard sent about upgrading from v7.

Hi Jeff,

I read the linked document, its most about new type names (xx_t) now, so this is solved quite good.

Unfortunately, the eco system from Intel wants to create two projects, one app and one bsp (board support package). Ok, but the app I get from the port is something very complicated, looks like a test suite for all features of FreeRTOS and something more.

I will try to set up some simpler, but I first have to find out how this scripts working. Awful system.

Problem is, that this two projects should be linked together, but no info how to do.

With best regards


Ahhhh, not so bad.

Have now the FreeRTOS kernel, compiles fine and a second project, the app, with an empty main and the kernel referenced this main (some init and startup code there), but …

Some missing links:

Think I will have a nice evening with this stuff … stay tuned.


Looks like alt_malloc_lock.c and alt_env_lock.c use vTaskDelay(), so you’ll want to define INCLUDE_vTaskDelay to 1 in FreeRTOSConfig.h.

And it looks like your FreeRTOSConfig.h has configCHECK_FOR_STACK_OVERFLOW defined to a nonzero value. That’s good. You’ll need to provide a vApplicationStackOverflowHook() function to handle stack overflow.