Help with failing build, fails with 'configTOTAL_HEAP_SIZE' undeclared here (not in a function)

[joostm8]

Hi,

I'm attempting to compile the MegaBlink example using Atmel Studio 7 for an Arduino Mega2560 EDIT: with the V10 FreeRTOS version.

In the defined Symbols I've added: F_CPU=16000000

__AVR_ATmega2560__

The include path directories include:

• ../FreeRTOS/include (FreeRTOS includes)
• ../lib/include (io library for serial comms)

I'm attempting to build with heap_4.c, so I've excluded the other heap files from the build.

As far as I'm aware, those configuration settings should suffice to build, yet, the build fails with the error

• 'configTOTAL_HEAP_SIZE' undeclared here (not in a function) in heap_4.c at line 66.

As far as I can deduce, configTOTAL_HEAP_SIZE should be defined by line 127 in FreeRTOSBoardDefs.h to be 0x1200, but somehow it remains undefined, as otherwise the error wouldn't be there.

Manually defining configTOTAL_HEAP_SIZE, e.g. in the main file, yields the same error, so I'm assuming it's undefined somewhere, yet a search for configTOTAL_HEAP_SIZE in the entire project does not find such an undef statement.

I have also recreated the project in MPLabX, yet I also hit the same error there.

I'm assuming this is simply user error, but is there any chance this is a known bug? I can of course provide more info as needed, as I'd love to have this error resolved.

Kind regards,

Joost

[feilipu]

I'll have a look, soon but buried in some other things now.

Not sure what Atmel Studio might be doing in the background. I use Eclipse.

[joostm8]

Alright no worries,

Given that Eclipse is your main development environment I figured I'd give it a shot as well. Followed the steps as per your article to build freeRTOSV10 as a static library with the AVR plugin for eclipse, and found the following:

• Heap 3 and 5 build without errors. Seems logical, as according to the FreeRTOS docs they don't use the configTOTAL_HEAP_SIZE parameter.
• Heaps 2, 4 and 1 fail with the same error as I got in Atmel Studio and MPLabX (defining __AVR_ATmega2560__ doesn't seem to make a difference)

I'm gonna do some brief experimenting with the other FreeRTOS builds as well, as for my application it doesn't specifically matter which version is used. I'll keep the thread posted.

EDIT: V8.2 works perfectly fine, tested in MPLabX as I'm also testing the MPLab SNAP programmer.

[feilipu]

I've checked the code, and I think the issue arises because configTOTAL_HEAP_SIZE is defined inside FreeRTOSBoardDefs.h, but it is bracketed by machine type. The machine type eg. __AVR_ATmega2560__ is normally defined automatically as part of my Eclipse environment. If your environment is not providing this symbol by default, then you'll get your issue.

Just define the symbol for your needs as needed, or cut down the FreeRTOSBoardDefs.h file to suit exactly what you need.

Is your project including FreeRTOSBoardDefs.h?

But, that doesn't explain why v8.2 works, unless I've developed the alternative builds much more since then.

[joostm8]

Sorry for the late update, I lost track of this issue a bit. I tested around a bit more creating the Eclipse project from scratch and such, using the internal vs external builder setting but can't seem to resolve it. The internal builder does yield a different error about configTICK_RATE_HZ.

In any case, these are just issues on my end. I wish I'd have found a definite solution, and it still doesn't quite explain why I can build 8.2 without problems but I'm closing this issue, as I'm near 100% certain it's not related to the code, rather to how my local build is happening.

[joostm8]

I'm reopening this issue as I did manage to figure out what was wrong, so I figured I'd document what I found out for future reference:

• In 8.2xx, "FreeRTOS.h" has the include statement for "FreeRTOSBoardDefs.h" on line 104, that's also why it builds without problems
• In 10.xx, this include statement is missing, and you need to add this manually (I added it back on line 65 in "FreeRTOS.h"). The eclipse "intellisense" is smarter than the build command, which makes it seem like all the proper definitions are in place, when in fact they aren't.
• Building then yields some undefined reference errors in vApplicationAssertHook for the prvBlinkMainLed and prvSetMainLedOn functions, I simply commented these to build with success. I assume you need to implement these for your specific hardware board, or alternatively you can disable assert.

That's all.

[feilipu]

Thanks. AFK currently, follow up with testing in a few weeks.